{"schema_version":"1.7.2","id":"OESA-2024-1621","modified":"2024-05-17T11:08:04Z","published":"2024-05-17T11:08:04Z","upstream":["CVE-2022-48655","CVE-2023-52477","CVE-2023-52618","CVE-2023-52620","CVE-2023-52628","CVE-2023-52642","CVE-2023-6270","CVE-2024-26668","CVE-2024-26669","CVE-2024-26671","CVE-2024-26680","CVE-2024-26688","CVE-2024-26689","CVE-2024-26791","CVE-2024-26792","CVE-2024-26811","CVE-2024-26812","CVE-2024-26817","CVE-2024-26828","CVE-2024-26839","CVE-2024-26840","CVE-2024-26843","CVE-2024-26855","CVE-2024-26870","CVE-2024-26875","CVE-2024-26878","CVE-2024-26893","CVE-2024-26898"],"summary":"kernel security update","details":"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\nfirmware: arm_scmi: Harden accesses to the reset domains\r\n\r\nAccessing reset domains descriptors by the index upon the SCMI drivers\nrequests through the SCMI reset operations interface can potentially\nlead to out-of-bound violations if the SCMI driver misbehave.\r\n\r\nAdd an internal consistency check before any such domains descriptors\naccesses.(CVE-2022-48655)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: hub: Guard against accesses to uninitialized BOS descriptors\r\n\r\nMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h\naccess fields inside udev-\u0026gt;bos without checking if it was allocated and\ninitialized. If usb_get_bos_descriptor() fails for whatever\nreason, udev-\u0026gt;bos will be NULL and those accesses will result in a\ncrash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000018\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 \u0026lt;HASH:1f9e 1\u0026gt;\nHardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:hub_port_reset+0x193/0x788\nCode: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 \u0026lt;48\u0026gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9\nRSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310\nRDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840\nRBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0\nCall Trace:\nhub_event+0x73f/0x156e\n? hub_activate+0x5b7/0x68f\nprocess_one_work+0x1a2/0x487\nworker_thread+0x11a/0x288\nkthread+0x13a/0x152\n? process_one_work+0x487/0x487\n? kthread_associate_blkcg+0x70/0x70\nret_from_fork+0x1f/0x30\r\n\r\nFall back to a default behavior if the BOS descriptor isn\u0026apos;t accessible\nand skip all the functionalities that depend on it: LPM support checks,\nSuper Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock/rnbd-srv: Check for unlikely string overflow\r\n\r\nSince \u0026quot;dev_search_path\u0026quot; can technically be as large as PATH_MAX,\nthere was a risk of truncation when copying it and a second string\ninto \u0026quot;full_path\u0026quot; since it was also PATH_MAX sized. The W=1 builds were\nreporting this warning:\r\n\r\ndrivers/block/rnbd/rnbd-srv.c: In function \u0026apos;process_msg_open.isra\u0026apos;:\ndrivers/block/rnbd/rnbd-srv.c:616:51: warning: \u0026apos;%s\u0026apos; directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]\n  616 |                 snprintf(full_path, PATH_MAX, \u0026quot;%s/%s\u0026quot;,\n      |                                                   ^~\nIn function \u0026apos;rnbd_srv_get_full_path\u0026apos;,\n    inlined from \u0026apos;process_msg_open.isra\u0026apos; at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: \u0026apos;snprintf\u0026apos; output between 2 and 4351 bytes into a destination of size 4096\n  616 |                 snprintf(full_path, PATH_MAX, \u0026quot;%s/%s\u0026quot;,\n      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n  617 |                          dev_search_path, dev_name);\n      |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n\r\nTo fix this, unconditionally check for truncation (as was already done\nfor the case where \u0026quot;%SESSNAME%\u0026quot; was present).(CVE-2023-52618)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: disallow timeout for anonymous sets\r\n\r\nNever used from userspace, disallow these parameters.(CVE-2023-52620)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nftables: exthdr: fix 4-byte stack OOB write\r\n\r\nIf priv-\u0026gt;len is a multiple of 4, then dst[len / 4] can write past\nthe destination array which leads to stack corruption.\r\n\r\nThis construct is necessary to clean the remainder of the register\nin case -\u0026gt;len is NOT a multiple of the register size, so make it\nconditional just like nft_payload.c does.\r\n\r\nThe bug was added in 4.1 cycle and then copied/inherited when\ntcp/sctp and ip option support was added.\r\n\r\nBug reported by Zero Day Initiative project (ZDI-CAN-21950,\nZDI-CAN-21951, ZDI-CAN-21961).(CVE-2023-52628)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: rc: bpf attach/detach requires write permission\r\n\r\nNote that bpf attach/detach also requires CAP_NET_ADMIN.(CVE-2023-52642)\r\n\r\nA flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.(CVE-2023-6270)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_limit: reject configurations that cause integer overflow\r\n\r\nReject bogus configs where internal token counter wraps around.\nThis only occurs with very very large requests, such as 17gbyte/s.\r\n\r\nIts better to reject this rather than having incorrect ratelimit.(CVE-2024-26668)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: flower: Fix chain template offload\r\n\r\nWhen a qdisc is deleted from a net device the stack instructs the\nunderlying driver to remove its flow offload callback from the\nassociated filter block using the \u0026apos;FLOW_BLOCK_UNBIND\u0026apos; command. The stack\nthen continues to replay the removal of the filters in the block for\nthis driver by iterating over the chains in the block and invoking the\n\u0026apos;reoffload\u0026apos; operation of the classifier being used. In turn, the\nclassifier in its \u0026apos;reoffload\u0026apos; operation prepares and emits a\n\u0026apos;FLOW_CLS_DESTROY\u0026apos; command for each filter.\r\n\r\nHowever, the stack does not do the same for chain templates and the\nunderlying driver never receives a \u0026apos;FLOW_CLS_TMPLT_DESTROY\u0026apos; command when\na qdisc is deleted. This results in a memory leak [1] which can be\nreproduced using [2].\r\n\r\nFix by introducing a \u0026apos;tmplt_reoffload\u0026apos; operation and have the stack\ninvoke it with the appropriate arguments as part of the replay.\nImplement the operation in the sole classifier that supports chain\ntemplates (flower) by emitting the \u0026apos;FLOW_CLS_TMPLT_{CREATE,DESTROY}\u0026apos;\ncommand based on whether a flow offload callback is being bound to a\nfilter block or being unbound from one.\r\n\r\nAs far as I can tell, the issue happens since cited commit which\nreordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()\nin __tcf_block_put(). The order cannot be reversed as the filter block\nis expected to be freed after flushing all the chains.\r\n\r\n[1]\nunreferenced object 0xffff888107e28800 (size 2048):\n  comm \u0026quot;tc\u0026quot;, pid 1079, jiffies 4294958525 (age 3074.287s)\n  hex dump (first 32 bytes):\n    b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff  ..|......[......\n    01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff  ................\n  backtrace:\n    [\u0026lt;ffffffff81c06a68\u0026gt;] __kmem_cache_alloc_node+0x1e8/0x320\n    [\u0026lt;ffffffff81ab374e\u0026gt;] __kmalloc+0x4e/0x90\n    [\u0026lt;ffffffff832aec6d\u0026gt;] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0\n    [\u0026lt;ffffffff832bc195\u0026gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180\n    [\u0026lt;ffffffff832b2e1a\u0026gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280\n    [\u0026lt;ffffffff83a10613\u0026gt;] tc_setup_cb_call+0x183/0x340\n    [\u0026lt;ffffffff83a9f85a\u0026gt;] fl_tmplt_create+0x3da/0x4c0\n    [\u0026lt;ffffffff83a22435\u0026gt;] tc_ctl_chain+0xa15/0x1170\n    [\u0026lt;ffffffff838a863c\u0026gt;] rtnetlink_rcv_msg+0x3cc/0xed0\n    [\u0026lt;ffffffff83ac87f0\u0026gt;] netlink_rcv_skb+0x170/0x440\n    [\u0026lt;ffffffff83ac6270\u0026gt;] netlink_unicast+0x540/0x820\n    [\u0026lt;ffffffff83ac6e28\u0026gt;] netlink_sendmsg+0x8d8/0xda0\n    [\u0026lt;ffffffff83793def\u0026gt;] ____sys_sendmsg+0x30f/0xa80\n    [\u0026lt;ffffffff8379d29a\u0026gt;] ___sys_sendmsg+0x13a/0x1e0\n    [\u0026lt;ffffffff8379d50c\u0026gt;] __sys_sendmsg+0x11c/0x1f0\n    [\u0026lt;ffffffff843b9ce0\u0026gt;] do_syscall_64+0x40/0xe0\nunreferenced object 0xffff88816d2c0400 (size 1024):\n  comm \u0026quot;tc\u0026quot;, pid 1079, jiffies 4294958525 (age 3074.287s)\n  hex dump (first 32 bytes):\n    40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00  @.......W.8.....\n    10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff  ..,m......,m....\n  backtrace:\n    [\u0026lt;ffffffff81c06a68\u0026gt;] __kmem_cache_alloc_node+0x1e8/0x320\n    [\u0026lt;ffffffff81ab36c1\u0026gt;] __kmalloc_node+0x51/0x90\n    [\u0026lt;ffffffff81a8ed96\u0026gt;] kvmalloc_node+0xa6/0x1f0\n    [\u0026lt;ffffffff82827d03\u0026gt;] bucket_table_alloc.isra.0+0x83/0x460\n    [\u0026lt;ffffffff82828d2b\u0026gt;] rhashtable_init+0x43b/0x7c0\n    [\u0026lt;ffffffff832aed48\u0026gt;] mlxsw_sp_acl_ruleset_get+0x428/0x7a0\n    [\u0026lt;ffffffff832bc195\u0026gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180\n    [\u0026lt;ffffffff832b2e1a\u0026gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280\n    [\u0026lt;ffffffff83a10613\u0026gt;] tc_setup_cb_call+0x183/0x340\n    [\u0026lt;ffffffff83a9f85a\u0026gt;] fl_tmplt_create+0x3da/0x4c0\n    [\u0026lt;ffffffff83a22435\u0026gt;] tc_ctl_chain+0xa15/0x1170\n    [\u0026lt;ffffffff838a863c\u0026gt;] rtnetlink_rcv_msg+0x3cc/0xed0\n    [\u0026lt;ffffffff83ac87f0\u0026gt;] netlink_rcv_skb+0x170/0x440\n    [\u0026lt;ffffffff83ac6270\u0026gt;] netlink_unicast+0x540/0x820\n    [\u0026lt;ffffffff83ac6e28\u0026gt;] netlink_sendmsg+0x8d8/0xda0\n    [\u0026lt;ffffffff83793def\u0026gt;] ____sys_sendmsg+0x30f/0xa80\r\n\r\n[2]\n # tc qdisc add dev swp1 clsact\n # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32\n # tc qdisc del dev\n---truncated---(CVE-2024-26669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-mq: fix IO hang from sbitmap wakeup race\r\n\r\nIn blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered\nwith the following blk_mq_get_driver_tag() in case of getting driver\ntag failure.\r\n\r\nThen in __sbitmap_queue_wake_up(), waitqueue_active() may not observe\nthe added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime\nblk_mq_mark_tag_wait() can\u0026apos;t get driver tag successfully.\r\n\r\nThis issue can be reproduced by running the following test in loop, and\nfio hang can be observed in \u0026lt; 30min when running it on my test VM\nin laptop.\r\n\r\n\tmodprobe -r scsi_debug\n\tmodprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4\n\tdev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`\n\tfio --filename=/dev/\u0026quot;$dev\u0026quot; --direct=1 --rw=randrw --bs=4k --iodepth=1 \\\n       \t\t--runtime=100 --numjobs=40 --time_based --name=test \\\n        \t--ioengine=libaio\r\n\r\nFix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which\nis just fine in case of running out of tag.(CVE-2024-26671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: atlantic: Fix DMA mapping for PTP hwts ring\r\n\r\nFunction aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes\nfor PTP HWTS ring but then generic aq_ring_free() does not take this\ninto account.\nCreate and use a specific function to free HWTS ring to fix this\nissue.\r\n\r\nTrace:\n[  215.351607] ------------[ cut here ]------------\n[  215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]\n[  215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360\n...\n[  215.581176] Call Trace:\n[  215.583632]  \u0026lt;TASK\u0026gt;\n[  215.585745]  ? show_trace_log_lvl+0x1c4/0x2df\n[  215.590114]  ? show_trace_log_lvl+0x1c4/0x2df\n[  215.594497]  ? debug_dma_free_coherent+0x196/0x210\n[  215.599305]  ? check_unmap+0xa6f/0x2360\n[  215.603147]  ? __warn+0xca/0x1d0\n[  215.606391]  ? check_unmap+0xa6f/0x2360\n[  215.610237]  ? report_bug+0x1ef/0x370\n[  215.613921]  ? handle_bug+0x3c/0x70\n[  215.617423]  ? exc_invalid_op+0x14/0x50\n[  215.621269]  ? asm_exc_invalid_op+0x16/0x20\n[  215.625480]  ? check_unmap+0xa6f/0x2360\n[  215.629331]  ? mark_lock.part.0+0xca/0xa40\n[  215.633445]  debug_dma_free_coherent+0x196/0x210\n[  215.638079]  ? __pfx_debug_dma_free_coherent+0x10/0x10\n[  215.643242]  ? slab_free_freelist_hook+0x11d/0x1d0\n[  215.648060]  dma_free_attrs+0x6d/0x130\n[  215.651834]  aq_ring_free+0x193/0x290 [atlantic]\n[  215.656487]  aq_ptp_ring_free+0x67/0x110 [atlantic]\n...\n[  216.127540] ---[ end trace 6467e5964dd2640b ]---\n[  216.132160] DMA-API: Mapped at:\n[  216.132162]  debug_dma_alloc_coherent+0x66/0x2f0\n[  216.132165]  dma_alloc_attrs+0xf5/0x1b0\n[  216.132168]  aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]\n[  216.132193]  aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]\n[  216.132213]  aq_nic_init+0x4a1/0x760 [atlantic](CVE-2024-26680)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super\r\n\r\nWhen configuring a hugetlb filesystem via the fsconfig() syscall, there is\na possible NULL dereference in hugetlbfs_fill_super() caused by assigning\nNULL to ctx-\u0026gt;hstate in hugetlbfs_parse_param() when the requested pagesize\nis non valid.\r\n\r\nE.g: Taking the following steps:\r\n\r\n     fd = fsopen(\u0026quot;hugetlbfs\u0026quot;, FSOPEN_CLOEXEC);\n     fsconfig(fd, FSCONFIG_SET_STRING, \u0026quot;pagesize\u0026quot;, \u0026quot;1024\u0026quot;, 0);\n     fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);\r\n\r\nGiven that the requested \u0026quot;pagesize\u0026quot; is invalid, ctxt-\u0026gt;hstate will be replaced\nwith NULL, losing its previous value, and we will print an error:\r\n\r\n ...\n ...\n case Opt_pagesize:\n ps = memparse(param-\u0026gt;string, \u0026amp;rest);\n ctx-\u0026gt;hstate = h;\n if (!ctx-\u0026gt;hstate) {\n         pr_err(\u0026quot;Unsupported page size %lu MB\\n\u0026quot;, ps / SZ_1M);\n         return -EINVAL;\n }\n return 0;\n ...\n ...\r\n\r\nThis is a problem because later on, we will dereference ctxt-\u0026gt;hstate in\nhugetlbfs_fill_super()\r\n\r\n ...\n ...\n sb-\u0026gt;s_blocksize = huge_page_size(ctx-\u0026gt;hstate);\n ...\n ...\r\n\r\nCausing below Oops.\r\n\r\nFix this by replacing cxt-\u0026gt;hstate value only when then pagesize is known\nto be valid.\r\n\r\n kernel: hugetlbfs: Unsupported page size 0 MB\n kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028\n kernel: #PF: supervisor read access in kernel mode\n kernel: #PF: error_code(0x0000) - not-present page\n kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0\n kernel: Oops: 0000 [#1] PREEMPT SMP PTI\n kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G            E      6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f\n kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017\n kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0\n kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 \u0026lt;8b\u0026gt; 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28\n kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246\n kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004\n kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000\n kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004\n kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000\n kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400\n kernel: FS:  00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000\n kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0\n kernel: Call Trace:\n kernel:  \u0026lt;TASK\u0026gt;\n kernel:  ? __die_body+0x1a/0x60\n kernel:  ? page_fault_oops+0x16f/0x4a0\n kernel:  ? search_bpf_extables+0x65/0x70\n kernel:  ? fixup_exception+0x22/0x310\n kernel:  ? exc_page_fault+0x69/0x150\n kernel:  ? asm_exc_page_fault+0x22/0x30\n kernel:  ? __pfx_hugetlbfs_fill_super+0x10/0x10\n kernel:  ? hugetlbfs_fill_super+0xb4/0x1a0\n kernel:  ? hugetlbfs_fill_super+0x28/0x1a0\n kernel:  ? __pfx_hugetlbfs_fill_super+0x10/0x10\n kernel:  vfs_get_super+0x40/0xa0\n kernel:  ? __pfx_bpf_lsm_capable+0x10/0x10\n kernel:  vfs_get_tree+0x25/0xd0\n kernel:  vfs_cmd_create+0x64/0xe0\n kernel:  __x64_sys_fsconfig+0x395/0x410\n kernel:  do_syscall_64+0x80/0x160\n kernel:  ? syscall_exit_to_user_mode+0x82/0x240\n kernel:  ? do_syscall_64+0x8d/0x160\n kernel:  ? syscall_exit_to_user_mode+0x82/0x240\n kernel:  ? do_syscall_64+0x8d/0x160\n kernel:  ? exc_page_fault+0x69/0x150\n kernel:  entry_SYSCALL_64_after_hwframe+0x6e/0x76\n kernel: RIP: 0033:0x7ffbc0cb87c9\n kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 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 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48\n kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af\n kernel: RAX: fffffffffff\n---truncated---(CVE-2024-26688)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nceph: prevent use-after-free in encode_cap_msg()\r\n\r\nIn fs/ceph/caps.c, in encode_cap_msg(), \u0026quot;use after free\u0026quot; error was\ncaught by KASAN at this line - \u0026apos;ceph_buffer_get(arg-\u0026gt;xattr_buf);\u0026apos;. This\nimplies before the refcount could be increment here, it was freed.\r\n\r\nIn same file, in \u0026quot;handle_cap_grant()\u0026quot; refcount is decremented by this\nline - \u0026apos;ceph_buffer_put(ci-\u0026gt;i_xattrs.blob);\u0026apos;. It appears that a race\noccurred and resource was freed by the latter line before the former\nline could increment it.\r\n\r\nencode_cap_msg() is called by __send_cap() and __send_cap() is called by\nceph_check_caps() after calling __prep_cap(). __prep_cap() is where\narg-\u0026gt;xattr_buf is assigned to ci-\u0026gt;i_xattrs.blob. This is the spot where\nthe refcount must be increased to prevent \u0026quot;use after free\u0026quot; error.(CVE-2024-26689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: dev-replace: properly validate device names\r\n\r\nThere\u0026apos;s a syzbot report that device name buffers passed to device\nreplace are not properly checked for string termination which could lead\nto a read out of bounds in getname_kernel().\r\n\r\nAdd a helper that validates both source and target device name buffers.\nFor devid as the source initialize the buffer to empty string in case\nsomething tries to read it later.\r\n\r\nThis was originally analyzed and fixed in a different way by Edward Adam\nDavis (see links).(CVE-2024-26791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix double free of anonymous device after snapshot creation failure\r\n\r\nWhen creating a snapshot we may do a double free of an anonymous device\nin case there\u0026apos;s an error committing the transaction. The second free may\nresult in freeing an anonymous device number that was allocated by some\nother subsystem in the kernel or another btrfs filesystem.\r\n\r\nThe steps that lead to this:\r\n\r\n1) At ioctl.c:create_snapshot() we allocate an anonymous device number\n   and assign it to pending_snapshot-\u0026gt;anon_dev;\r\n\r\n2) Then we call btrfs_commit_transaction() and end up at\n   transaction.c:create_pending_snapshot();\r\n\r\n3) There we call btrfs_get_new_fs_root() and pass it the anonymous device\n   number stored in pending_snapshot-\u0026gt;anon_dev;\r\n\r\n4) btrfs_get_new_fs_root() frees that anonymous device number because\n   btrfs_lookup_fs_root() returned a root - someone else did a lookup\n   of the new root already, which could some task doing backref walking;\r\n\r\n5) After that some error happens in the transaction commit path, and at\n   ioctl.c:create_snapshot() we jump to the \u0026apos;fail\u0026apos; label, and after\n   that we free again the same anonymous device number, which in the\n   meanwhile may have been reallocated somewhere else, because\n   pending_snapshot-\u0026gt;anon_dev still has the same value as in step 1.\r\n\r\nRecently syzbot ran into this and reported the following trace:\r\n\r\n  ------------[ cut here ]------------\n  ida_free called for id=51 which is not allocated.\n  WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525\n  Modules linked in:\n  CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\n  RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525\n  Code: 10 42 80 3c 28 (...)\n  RSP: 0018:ffffc90015a67300 EFLAGS: 00010246\n  RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000\n  RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000\n  RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4\n  R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246\n  R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246\n  FS:  00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346\n   create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837\n   create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931\n   btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404\n   create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848\n   btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998\n   btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044\n   __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306\n   btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393\n   btrfs_ioctl+0xa74/0xd40\n   vfs_ioctl fs/ioctl.c:51 [inline]\n   __do_sys_ioctl fs/ioctl.c:871 [inline]\n   __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857\n   do_syscall_64+0xfb/0x240\n   entry_SYSCALL_64_after_hwframe+0x6f/0x77\n  RIP: 0033:0x7fca3e67dda9\n  Code: 28 00 00 00 (...)\n  RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n  RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9\n  RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003\n  RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n  R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658\n   \u0026lt;/TASK\u0026gt;\r\n\r\nWhere we get an explicit message where we attempt to free an anonymous\ndevice number that is not currently allocated. It happens in a different\ncode path from the example below, at btrfs_get_root_ref(), so this change\nmay not fix the case triggered by sy\n---truncated---(CVE-2024-26792)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: validate payload size in ipc response\r\n\r\nIf installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc\nresponse to ksmbd kernel server. ksmbd should validate payload size of\nipc response from ksmbd.mountd to avoid memory overrun or\nslab-out-of-bounds. This patch validate 3 ipc response that has payload.(CVE-2024-26811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: Create persistent INTx handler\r\n\r\nA vulnerability exists where the eventfd for INTx signaling can be\ndeconfigured, which unregisters the IRQ handler but still allows\neventfds to be signaled with a NULL context through the SET_IRQS ioctl\nor through unmask irqfd if the device interrupt is pending.\r\n\r\nIdeally this could be solved with some additional locking; the igate\nmutex serializes the ioctl and config space accesses, and the interrupt\nhandler is unregistered relative to the trigger, but the irqfd path\nruns asynchronous to those.  The igate mutex cannot be acquired from the\natomic context of the eventfd wake function.  Disabling the irqfd\nrelative to the eventfd registration is potentially incompatible with\nexisting userspace.\r\n\r\nAs a result, the solution implemented here moves configuration of the\nINTx interrupt handler to track the lifetime of the INTx context object\nand irq_type configuration, rather than registration of a particular\ntrigger eventfd.  Synchronization is added between the ioctl path and\neventfd_signal() wrapper such that the eventfd trigger can be\ndynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\namdkfd: use calloc instead of kzalloc to avoid integer overflow\r\n\r\nThis uses calloc instead of doing the multiplication which might\noverflow.(CVE-2024-26817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncifs: fix underflow in parse_server_interfaces()\r\n\r\nIn this loop, we step through the buffer and after each item we check\nif the size_left is greater than the minimum size we need.  However,\nthe problem is that \u0026quot;bytes_left\u0026quot; is type ssize_t while sizeof() is type\nsize_t.  That means that because of type promotion, the comparison is\ndone as an unsigned and if we have negative bytes left the loop\ncontinues instead of ending.(CVE-2024-26828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/hfi1: Fix a memleak in init_credit_return\r\n\r\nWhen dma_alloc_coherent fails to allocate dd-\u0026gt;cr_base[i].va,\ninit_credit_return should deallocate dd-\u0026gt;cr_base and\ndd-\u0026gt;cr_base[i] that allocated before. Or those resources\nwould be never freed and a memleak is triggered.(CVE-2024-26839)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: fix memory leak in cachefiles_add_cache()\r\n\r\nThe following memory leak was reported after unbinding /dev/cachefiles:\r\n\r\n==================================================================\nunreferenced object 0xffff9b674176e3c0 (size 192):\n  comm \u0026quot;cachefilesd2\u0026quot;, pid 680, jiffies 4294881224\n  hex dump (first 32 bytes):\n    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace (crc ea38a44b):\n    [\u0026lt;ffffffff8eb8a1a5\u0026gt;] kmem_cache_alloc+0x2d5/0x370\n    [\u0026lt;ffffffff8e917f86\u0026gt;] prepare_creds+0x26/0x2e0\n    [\u0026lt;ffffffffc002eeef\u0026gt;] cachefiles_determine_cache_security+0x1f/0x120\n    [\u0026lt;ffffffffc00243ec\u0026gt;] cachefiles_add_cache+0x13c/0x3a0\n    [\u0026lt;ffffffffc0025216\u0026gt;] cachefiles_daemon_write+0x146/0x1c0\n    [\u0026lt;ffffffff8ebc4a3b\u0026gt;] vfs_write+0xcb/0x520\n    [\u0026lt;ffffffff8ebc5069\u0026gt;] ksys_write+0x69/0xf0\n    [\u0026lt;ffffffff8f6d4662\u0026gt;] do_syscall_64+0x72/0x140\n    [\u0026lt;ffffffff8f8000aa\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n==================================================================\r\n\r\nPut the reference count of cache_cred in cachefiles_daemon_unbind() to\nfix the problem. And also put cache_cred in cachefiles_add_cache() error\nbranch to avoid memory leaks.(CVE-2024-26840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi: runtime: Fix potential overflow of soft-reserved region size\r\n\r\nmd_size will have been narrowed if we have \u0026gt;= 4GB worth of pages in a\nsoft-reserved region.(CVE-2024-26843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()\r\n\r\nThe function ice_bridge_setlink() may encounter a NULL pointer dereference\nif nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently\nin nla_for_each_nested(). To address this issue, add a check to ensure that\nbr_spec is not NULL before proceeding with the nested attribute iteration.(CVE-2024-26855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102\r\n\r\nA call to listxattr() with a buffer size = 0 returns the actual\nsize of the buffer needed for a subsequent call. When size \u0026gt; 0,\nnfs4_listxattr() does not return an error because either\ngeneric_listxattr() or nfs4_listxattr_nfs4_label() consumes\nexactly all the bytes then size is 0 when calling\nnfs4_listxattr_nfs4_user() which then triggers the following\nkernel BUG:\r\n\r\n  [   99.403778] kernel BUG at mm/usercopy.c:102!\n  [   99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n  [   99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1\n  [   99.415827] Call trace:\n  [   99.415985]  usercopy_abort+0x70/0xa0\n  [   99.416227]  __check_heap_object+0x134/0x158\n  [   99.416505]  check_heap_object+0x150/0x188\n  [   99.416696]  __check_object_size.part.0+0x78/0x168\n  [   99.416886]  __check_object_size+0x28/0x40\n  [   99.417078]  listxattr+0x8c/0x120\n  [   99.417252]  path_listxattr+0x78/0xe0\n  [   99.417476]  __arm64_sys_listxattr+0x28/0x40\n  [   99.417723]  invoke_syscall+0x78/0x100\n  [   99.417929]  el0_svc_common.constprop.0+0x48/0xf0\n  [   99.418186]  do_el0_svc+0x24/0x38\n  [   99.418376]  el0_svc+0x3c/0x110\n  [   99.418554]  el0t_64_sync_handler+0x120/0x130\n  [   99.418788]  el0t_64_sync+0x194/0x198\n  [   99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)\r\n\r\nIssue is reproduced when generic_listxattr() returns \u0026apos;system.nfs4_acl\u0026apos;,\nthus calling lisxattr() with size = 16 will trigger the bug.\r\n\r\nAdd check on nfs4_listxattr() to return ERANGE error when it is\ncalled with size \u0026gt; 0 and the return value is greater than size.(CVE-2024-26870)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: pvrusb2: fix uaf in pvr2_context_set_notify\r\n\r\n[Syzbot reported]\nBUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35\nRead of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26\r\n\r\nCPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc4/0x620 mm/kasan/report.c:488\n kasan_report+0xda/0x110 mm/kasan/report.c:601\n pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35\n pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]\n pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272\r\n\r\nFreed by task 906:\nkasan_save_stack+0x33/0x50 mm/kasan/common.c:47\nkasan_save_track+0x14/0x30 mm/kasan/common.c:68\nkasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640\npoison_slab_object mm/kasan/common.c:241 [inline]\n__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257\nkasan_slab_free include/linux/kasan.h:184 [inline]\nslab_free_hook mm/slub.c:2121 [inline]\nslab_free mm/slub.c:4299 [inline]\nkfree+0x105/0x340 mm/slub.c:4409\npvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]\npvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158\r\n\r\n[Analyze]\nTask A set disconnect_flag = !0, which resulted in Task B\u0026apos;s condition being met\nand releasing mp, leading to this issue.\r\n\r\n[Fix]\nPlace the disconnect_flag assignment operation after all code in pvr2_context_disconnect()\nto avoid this issue.(CVE-2024-26875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nquota: Fix potential NULL pointer dereference\r\n\r\nBelow race may cause NULL pointer dereference\r\n\r\nP1\t\t\t\t\tP2\ndquot_free_inode\t\t\tquota_off\n\t\t\t\t\t  drop_dquot_ref\n\t\t\t\t\t   remove_dquot_ref\n\t\t\t\t\t   dquots = i_dquot(inode)\n  dquots = i_dquot(inode)\n  srcu_read_lock\n  dquots[cnt]) != NULL (1)\n\t\t\t\t\t     dquots[type] = NULL (2)\n  spin_lock(\u0026amp;dquots[cnt]-\u0026gt;dq_dqb_lock) (3)\n   ....\r\n\r\nIf dquot_free_inode(or other routines) checks inode\u0026apos;s quota pointers (1)\nbefore quota_off sets it to NULL(2) and use it (3) after that, NULL pointer\ndereference will be triggered.\r\n\r\nSo let\u0026apos;s fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: arm_scmi: Fix double free in SMC transport cleanup path\r\n\r\nWhen the generic SCMI code tears down a channel, it calls the chan_free\ncallback function, defined by each transport. Since multiple protocols\nmight share the same transport_info member, chan_free() might want to\nclean up the same member multiple times within the given SCMI transport\nimplementation. In this case, it is SMC transport. This will lead to a NULL\npointer dereference at the second time:\r\n\r\n    | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16\n    | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.\n    | arm-scmi firmware:scmi: unable to communicate with SCMI\n    | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n    | Mem abort info:\n    |   ESR = 0x0000000096000004\n    |   EC = 0x25: DABT (current EL), IL = 32 bits\n    |   SET = 0, FnV = 0\n    |   EA = 0, S1PTW = 0\n    |   FSC = 0x04: level 0 translation fault\n    | Data abort info:\n    |   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n    |   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n    |   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n    | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000\n    | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n    | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n    | Modules linked in:\n    | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793\n    | Hardware name: FVP Base RevC (DT)\n    | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n    | pc : smc_chan_free+0x3c/0x6c\n    | lr : smc_chan_free+0x3c/0x6c\n    | Call trace:\n    |  smc_chan_free+0x3c/0x6c\n    |  idr_for_each+0x68/0xf8\n    |  scmi_cleanup_channels.isra.0+0x2c/0x58\n    |  scmi_probe+0x434/0x734\n    |  platform_probe+0x68/0xd8\n    |  really_probe+0x110/0x27c\n    |  __driver_probe_device+0x78/0x12c\n    |  driver_probe_device+0x3c/0x118\n    |  __driver_attach+0x74/0x128\n    |  bus_for_each_dev+0x78/0xe0\n    |  driver_attach+0x24/0x30\n    |  bus_add_driver+0xe4/0x1e8\n    |  driver_register+0x60/0x128\n    |  __platform_driver_register+0x28/0x34\n    |  scmi_driver_init+0x84/0xc0\n    |  do_one_initcall+0x78/0x33c\n    |  kernel_init_freeable+0x2b8/0x51c\n    |  kernel_init+0x24/0x130\n    |  ret_from_fork+0x10/0x20\n    | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)\n    | ---[ end trace 0000000000000000 ]---\r\n\r\nSimply check for the struct pointer being NULL before trying to access\nits members, to avoid this situation.\r\n\r\nThis was found when a transport doesn\u0026apos;t really work (for instance no SMC\nservice), the probe routines then tries to clean up, and triggers a crash.(CVE-2024-26893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\naoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\r\n\r\nThis patch is against CVE-2023-6270. The description of cve is:\r\n\r\n  A flaw was found in the ATA over Ethernet (AoE) driver in the Linux\n  kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on\n  `struct net_device`, and a use-after-free can be triggered by racing\n  between the free on the struct and the access through the `skbtxq`\n  global queue. This could lead to a denial of service condition or\n  potential code execution.\r\n\r\nIn aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial\ncode is finished. But the net_device ifp will still be used in\nlater tx()-\u0026gt;dev_queue_xmit() in kthread. Which means that the\ndev_put(ifp) should NOT be called in the success path of skb\ninitial code in aoecmd_cfg_pkts(). Otherwise tx() may run into\nuse-after-free because the net_device is freed.\r\n\r\nThis patch removed the dev_put(ifp) in the success path in\naoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().(CVE-2024-26898)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP2","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP2"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-153.54.0.132.oe2203sp2"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","kernel-headers-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","kernel-debuginfo-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","kernel-tools-debuginfo-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","kernel-tools-devel-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","kernel-tools-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","python3-perf-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","kernel-source-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","perf-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","python3-perf-debuginfo-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","perf-debuginfo-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","kernel-devel-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm","kernel-debugsource-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm"],"src":["kernel-5.10.0-153.54.0.132.oe2203sp2.src.rpm"],"x86_64":["kernel-source-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","kernel-headers-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","python3-perf-debuginfo-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","python3-perf-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","kernel-devel-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","kernel-tools-debuginfo-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","kernel-tools-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","kernel-debugsource-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","kernel-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","kernel-debuginfo-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","kernel-tools-devel-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","perf-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm","perf-debuginfo-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1621"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48655"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52477"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52618"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52620"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52628"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52642"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-6270"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26668"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26669"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26671"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26680"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26688"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26689"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26791"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26792"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26811"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26812"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26817"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26828"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26839"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26840"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26843"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26855"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26870"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26875"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26878"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26893"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26898"}],"database_specific":{"severity":"High"}}