14 lines
20 KiB
JSON
14 lines
20 KiB
JSON
{
|
|
"id": "openEuler-SA-2024-1394",
|
|
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1394",
|
|
"title": "An update for kernel is now available for openEuler-22.03-LTS",
|
|
"severity": "High",
|
|
"description": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: hda: intel-sdw-acpi: harden detection of controller\r\n\r\nThe existing code currently sets a pointer to an ACPI handle before\nchecking that it's actually a SoundWire controller. This can lead to\nissues where the graph walk continues and eventually fails, but the\npointer was set already.\r\n\r\nThis patch changes the logic so that the information provided to\nthe caller is set when a controller is found.(CVE-2021-46926)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: q6afe-clocks: fix reprobing of the driver\r\n\r\nQ6afe-clocks driver can get reprobed. For example if the APR services\nare restarted after the firmware crash. However currently Q6afe-clocks\ndriver will oops because hw.init will get cleared during first _probe\ncall. Rewrite the driver to fill the clock data at runtime rather than\nusing big static array of clocks.(CVE-2021-47037)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: avoid crash when parsed profile name is empty\r\n\r\nWhen processing a packed profile in unpack_profile() described like\r\n\r\n \"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}\"\r\n\r\na string \":samba-dcerpcd\" is unpacked as a fully-qualified name and then\npassed to aa_splitn_fqname().\r\n\r\naa_splitn_fqname() treats \":samba-dcerpcd\" as only containing a namespace.\nThus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later\naa_alloc_profile() crashes as the new profile name is NULL now.\r\n\r\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\nRIP: 0010:strlen+0x1e/0xa0\nCall Trace:\n <TASK>\n ? strlen+0x1e/0xa0\n aa_policy_init+0x1bb/0x230\n aa_alloc_profile+0xb1/0x480\n unpack_profile+0x3bc/0x4960\n aa_unpack+0x309/0x15e0\n aa_replace_profiles+0x213/0x33c0\n policy_update+0x261/0x370\n profile_replace+0x20e/0x2a0\n vfs_write+0x2af/0xe00\n ksys_write+0x126/0x250\n do_syscall_64+0x46/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n </TASK>\n---[ end trace 0000000000000000 ]---\nRIP: 0010:strlen+0x1e/0xa0\r\n\r\nIt seems such behaviour of aa_splitn_fqname() is expected and checked in\nother places where it is called (e.g. aa_remove_profiles). Well, there\nis an explicit comment \"a ns name without a following profile is allowed\"\ninside.\r\n\r\nAFAICS, nothing can prevent unpacked \"name\" to be in form like\n\":samba-dcerpcd\" - it is passed from userspace.\r\n\r\nDeny the whole profile set replacement in such case and inform user with\nEPROTO and an explaining message.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2023-52443)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\r\n\r\nIf the host sends an H2CData command with an invalid DATAL,\nthe kernel may crash in nvmet_tcp_build_pdu_iovec().\r\n\r\nUnable to handle kernel NULL pointer dereference at\nvirtual address 0000000000000000\nlr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]\nCall trace:\n process_one_work+0x174/0x3c8\n worker_thread+0x2d0/0x3e8\n kthread+0x104/0x110\r\n\r\nFix the bug by raising a fatal error if DATAL isn't coherent\nwith the packet size.\nAlso, the PDU length should never exceed the MAXH2CDATA parameter which\nhas been communicated to the host in nvmet_tcp_handle_icreq().(CVE-2023-52454)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: imx: fix tx statemachine deadlock\r\n\r\nWhen using the serial port as RS485 port, the tx statemachine is used to\ncontrol the RTS pin to drive the RS485 transceiver TX_EN pin. When the\nTTY port is closed in the middle of a transmission (for instance during\nuserland application crash), imx_uart_shutdown disables the interface\nand disables the Transmission Complete interrupt. afer that,\nimx_uart_stop_tx bails on an incomplete transmission, to be retriggered\nby the TC interrupt. This interrupt is disabled and therefore the tx\nstatemachine never transitions out of SEND. The statemachine is in\ndeadlock now, and the TX_EN remains low, making the interface useless.\r\n\r\nimx_uart_stop_tx now checks for incomplete transmission AND whether TC\ninterrupts are enabled before bailing to be retriggered. This makes sure\nthe state machine handling is reached, and is properly set to\nWAIT_AFTER_SEND.(CVE-2023-52456)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmfd: syscon: Fix null pointer dereference in of_syscon_register()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52467)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers/amd/pm: fix a use-after-free in kv_parse_power_table\r\n\r\nWhen ps allocated by kzalloc equals to NULL, kv_parse_power_table\nfrees adev->pm.dpm.ps that allocated before. However, after the control\nflow goes through the following call chains:\r\n\r\nkv_parse_power_table\n |-> kv_dpm_init\n |-> kv_dpm_sw_init\n\t |-> kv_dpm_fini\r\n\r\nThe adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its\nfirst free in kv_parse_power_table and causes a use-after-free bug.(CVE-2023-52469)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/x86/lbr: Filter vsyscall addresses\r\n\r\nWe found that a panic can occur when a vsyscall is made while LBR sampling\nis active. If the vsyscall is interrupted (NMI) for perf sampling, this\ncall sequence can occur (most recent at top):\r\n\r\n __insn_get_emulate_prefix()\n insn_get_emulate_prefix()\n insn_get_prefixes()\n insn_get_opcode()\n decode_branch_type()\n get_branch_type()\n intel_pmu_lbr_filter()\n intel_pmu_handle_irq()\n perf_event_nmi_handler()\r\n\r\nWithin __insn_get_emulate_prefix() at frame 0, a macro is called:\r\n\r\n peek_nbyte_next(insn_byte_t, insn, i)\r\n\r\nWithin this macro, this dereference occurs:\r\n\r\n (insn)->next_byte\r\n\r\nInspecting registers at this point, the value of the next_byte field is the\naddress of the vsyscall made, for example the location of the vsyscall\nversion of gettimeofday() at 0xffffffffff600000. The access to an address\nin the vsyscall region will trigger an oops due to an unhandled page fault.\r\n\r\nTo fix the bug, filtering for vsyscalls can be done when\ndetermining the branch type. This patch will return\na \"none\" branch if a kernel address if found to lie in the\nvsyscall region.(CVE-2023-52476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix uaf in smb20_oplock_break_ack\r\n\r\ndrop reference after use opinfo.(CVE-2023-52479)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range\r\n\r\nWhen running an SVA case, the following soft lockup is triggered:\n--------------------------------------------------------------------\nwatchdog: BUG: soft lockup - CPU#244 stuck for 26s!\npstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\npc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50\nlr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50\nsp : ffff8000d83ef290\nx29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000\nx26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000\nx23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0\nx20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0\nx14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a\nx2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001\nCall trace:\n arm_smmu_cmdq_issue_cmdlist+0x178/0xa50\n __arm_smmu_tlb_inv_range+0x118/0x254\n arm_smmu_tlb_inv_range_asid+0x6c/0x130\n arm_smmu_mm_invalidate_range+0xa0/0xa4\n __mmu_notifier_invalidate_range_end+0x88/0x120\n unmap_vmas+0x194/0x1e0\n unmap_region+0xb4/0x144\n do_mas_align_munmap+0x290/0x490\n do_mas_munmap+0xbc/0x124\n __vm_munmap+0xa8/0x19c\n __arm64_sys_munmap+0x28/0x50\n invoke_syscall+0x78/0x11c\n el0_svc_common.constprop.0+0x58/0x1c0\n do_el0_svc+0x34/0x60\n el0_svc+0x2c/0xd4\n el0t_64_sync_handler+0x114/0x140\n el0t_64_sync+0x1a4/0x1a8\n--------------------------------------------------------------------\r\n\r\nNote that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed\nto \"arm_smmu_mm_arch_invalidate_secondary_tlbs\", yet the problem remains.\r\n\r\nThe commit 06ff87bae8d3 (\"arm64: mm: remove unused functions and variable\nprotoypes\") fixed a similar lockup on the CPU MMU side. Yet, it can occur\nto SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called\ntypically next to MMU tlb flush function, e.g.\n\ttlb_flush_mmu_tlbonly {\n\t\ttlb_flush {\n\t\t\t__flush_tlb_range {\n\t\t\t\t// check MAX_TLBI_OPS\n\t\t\t}\n\t\t}\n\t\tmmu_notifier_arch_invalidate_secondary_tlbs {\n\t\t\tarm_smmu_mm_arch_invalidate_secondary_tlbs {\n\t\t\t\t// does not check MAX_TLBI_OPS\n\t\t\t}\n\t\t}\n\t}\r\n\r\nClone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an\nSVA case SMMU uses the CPU page table, so it makes sense to align with the\ntlbflush code. Then, replace per-page TLBI commands with a single per-asid\nTLBI command, if the request size hits this threshold.(CVE-2023-52484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntls: fix race between tx work scheduling and socket close\r\n\r\nSimilarly to previous commit, the submitting thread (recvmsg/sendmsg)\nmay exit as soon as the async crypto handler calls complete().\nReorder scheduling the work before calling complete().\nThis seems more logical in the first place, as it's\nthe inverse order of what the submitting thread will do.(CVE-2024-26585)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Reject variable offset alu on PTR_TO_FLOW_KEYS\r\n\r\nFor PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off\nfor validation. However, variable offset ptr alu is not prohibited\nfor this ptr kind. So the variable offset is not checked.\r\n\r\nThe following prog is accepted:\r\n\r\n func#0 @0\n 0: R1=ctx() R10=fp0\n 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx()\n 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys()\n 2: (b7) r8 = 1024 ; R8_w=1024\n 3: (37) r8 /= 1 ; R8_w=scalar()\n 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,\n smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))\n 5: (0f) r7 += r8\n mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1\n mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024\n mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1\n mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024\n 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off\n =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,\n var_off=(0x0; 0x400))\n 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar()\n 7: (95) exit\r\n\r\nThis prog loads flow_keys to r7, and adds the variable offset r8\nto r7, and finally causes out-of-bounds access:\r\n\r\n BUG: unable to handle page fault for address: ffffc90014c80038\n [...]\n Call Trace:\n <TASK>\n bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]\n __bpf_prog_run include/linux/filter.h:651 [inline]\n bpf_prog_run include/linux/filter.h:658 [inline]\n bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]\n bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991\n bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359\n bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]\n __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475\n __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]\n __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nFix this by rejecting ptr alu with variable offset on flow_keys.\nApplying the patch rejects the program with \"R7 pointer arithmetic\non flow_keys prohibited\".(CVE-2024-26589)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: i801: Fix block process call transactions\r\n\r\nAccording to the Intel datasheets, software must reset the block\nbuffer index twice for block process call transactions: once before\nwriting the outgoing data to the buffer, and once again before\nreading the incoming data from the buffer.\r\n\r\nThe driver is currently missing the second reset, causing the wrong\nportion of the block buffer to be read.(CVE-2024-26593)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: qualcomm: rmnet: fix global oob in rmnet_policy\r\n\r\nThe variable rmnet_link_ops assign a *bigger* maxtype which leads to a\nglobal out-of-bounds read when parsing the netlink attributes. See bug\ntrace below:\r\n\r\n==================================================================\nBUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]\nBUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600\nRead of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207\r\n\r\nCPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:284 [inline]\n print_report+0x172/0x475 mm/kasan/report.c:395\n kasan_report+0xbb/0x1c0 mm/kasan/report.c:495\n validate_nla lib/nlattr.c:386 [inline]\n __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600\n __nla_parse+0x3e/0x50 lib/nlattr.c:697\n nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]\n __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485\n rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594\n rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091\n netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg+0x154/0x190 net/socket.c:734\n ____sys_sendmsg+0x6df/0x840 net/socket.c:2482\n ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536\n __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7fdcf2072359\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359\nRDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003\nRBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000\n </TASK>\r\n\r\nThe buggy address belongs to the variable:\n rmnet_policy+0x30/0xe0\r\n\r\nThe buggy address belongs to the physical page:\npage:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243\nflags: 0x200000000001000(reserved|node=0|zone=2)\nraw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000\nraw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\r\n\r\nMemory state around the buggy address:\n ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07\n ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9\n>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9\n ^\n ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9\n ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9\r\n\r\nAccording to the comment of `nla_parse_nested_deprecated`, the maxtype\nshould be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.(CVE-2024-26597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP\r\n\r\nIf the external phy working together with phy-omap-usb2 does not implement\nsend_srp(), we may still attempt to call it. This can happen on an idle\nEthernet gadget triggering a wakeup for example:\r\n\r\nconfigfs-gadget.g1 gadget.0: ECM Suspend\nconfigfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup\n...\nUnable to handle kernel NULL pointer dereference at virtual address\n00000000 when execute\n...\nPC is at 0x0\nLR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]\n...\nmusb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]\nusb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]\neth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c\ndev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4\nsch_direct_xmit from __dev_queue_xmit+0x334/0xd88\n__dev_queue_xmit from arp_solicit+0xf0/0x268\narp_solicit from neigh_probe+0x54/0x7c\nneigh_probe from __neigh_event_send+0x22c/0x47c\n__neigh_event_send from neigh_resolve_output+0x14c/0x1c0\nneigh_resolve_output from ip_finish_output2+0x1c8/0x628\nip_finish_output2 from ip_send_skb+0x40/0xd8\nip_send_skb from udp_send_skb+0x124/0x340\nudp_send_skb from udp_sendmsg+0x780/0x984\nudp_sendmsg from __sys_sendto+0xd8/0x158\n__sys_sendto from ret_fast_syscall+0x0/0x58\r\n\r\nLet's fix the issue by checking for send_srp() and set_vbus() before\ncalling them. For USB peripheral only cases these both could be NULL.(CVE-2024-26600)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: signal epoll threads of self-work\r\n\r\nIn (e)poll mode, threads often depend on I/O events to determine when\ndata is ready for consumption. Within binder, a thread may initiate a\ncommand via BINDER_WRITE_READ without a read buffer and then make use\nof epoll_wait() or similar to consume any responses afterwards.\r\n\r\nIt is then crucial that epoll threads are signaled via wakeup when they\nqueue their own work. Otherwise, they risk waiting indefinitely for an\nevent leaving their work unhandled. What is worse, subsequent commands\nwon't trigger a wakeup either as the thread has pending work.(CVE-2024-26606)",
|
|
"cves": [
|
|
{
|
|
"id": "CVE-2024-26606",
|
|
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26606",
|
|
"severity": "Low"
|
|
}
|
|
]
|
|
} |