{"id":"OESA-2025-2659","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: tifm: fix possible memory leak in tifm_7xx1_switch_media()\n\nIf device_register() returns error in tifm_7xx1_switch_media(),\nname of kobject which is allocated in dev_set_name() called in device_add()\nis leaked.\n\nNever directly free @dev after calling device_register(), even\nif it returned an error! Always use put_device() to give up the\nreference initialized.(CVE-2022-50349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns: fix possible memory leak in hnae_ae_register()\n\nInject fault while probing module, if device_register() fails,\nbut the refcount of kobject is not decreased to 0, the name\nallocated in dev_set_name() is leaked. Fix this by calling\nput_device(), so that name can be freed in callback function\nkobject_cleanup().\n\nunreferenced object 0xffff00c01aba2100 (size 128):\n  comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s)\n  hex dump (first 32 bytes):\n    68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff  hnae0....!......\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0\n    [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0\n    [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390\n    [<000000006c0ffb13>] kvasprintf+0x8c/0x118\n    [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8\n    [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0\n    [<000000000b87affc>] dev_set_name+0x7c/0xa0\n    [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae]\n    [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf]\n    [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf](CVE-2022-50352)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid crash when inline data creation follows DIO write\n\nWhen inode is created and written to using direct IO, there is nothing\nto clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets\ntruncated later to say 1 byte and written using normal write, we will\ntry to store the data as inline data. This confuses the code later\nbecause the inode now has both normal block and inline data allocated\nand the confusion manifests for example as:\n\nkernel BUG at fs/ext4/inode.c:2721!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN\nCPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014\nRIP: 0010:ext4_writepages+0x363d/0x3660\nRSP: 0018:ffffc90000ccf260 EFLAGS: 00010293\nRAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180\nRDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000\nRBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b\nR10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128\nR13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001\nFS:  00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0\nCall Trace:\n <TASK>\n do_writepages+0x397/0x640\n filemap_fdatawrite_wbc+0x151/0x1b0\n file_write_and_wait_range+0x1c9/0x2b0\n ext4_sync_file+0x19e/0xa00\n vfs_fsync_range+0x17b/0x190\n ext4_buffered_write_iter+0x488/0x530\n ext4_file_write_iter+0x449/0x1b90\n vfs_write+0xbcd/0xf40\n ksys_write+0x198/0x2c0\n __x64_sys_write+0x7b/0x90\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n </TASK>\n\nFix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing\ndirect IO write to a file.(CVE-2022-50435)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clean up si_domain in the init_dmars() error path\n\nA splat from kmem_cache_destroy() was seen with a kernel prior to\ncommit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool")\nwhen there was a failure in init_dmars(), because the iommu_domain\ncache still had objects. While the mempool code is now gone, there\nstill is a leak of the si_domain memory if init_dmars() fails. So\nclean up si_domain in the init_dmars() error path.(CVE-2022-50482)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Fix potential memory leaks\n\nWhen the driver hits -ENOMEM at allocating a URB or a buffer, it\naborts and goes to the error path that releases the all previously\nallocated resources.  However, when -ENOMEM hits at the middle of the\nsync EP URB allocation loop, the partially allocated URBs might be\nleft without released, because ep->nurbs is still zero at that point.\n\nFix it by setting ep->nurbs at first, so that the error handler loops\nover the full URB list.(CVE-2022-50484)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mipi-dsi: Detach devices when removing the host\n\nWhenever the MIPI-DSI host is unregistered, the code of\nmipi_dsi_host_unregister() loops over every device currently found on that\nbus and will unregister it.\n\nHowever, it doesn't detach it from the bus first, which leads to all kind\nof resource leaks if the host wants to perform some clean up whenever a\ndevice is detached.(CVE-2022-50489)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios()\n\nAs comment of pci_get_class() says, it returns a pci_device with its\nrefcount increased and decreased the refcount for the input parameter\n@from if it is not NULL.\n\nIf we break the loop in radeon_atrm_get_bios() with 'pdev' not NULL, we\nneed to call pci_dev_put() to decrease the refcount. Add the missing\npci_dev_put() to avoid refcount leak.(CVE-2022-50520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix an information leak in tipc_topsrv_kern_subscr\n\nUse a 8-byte write to initialize sub.usr_handle in\ntipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized\nwhen issuing setsockopt(..., SOL_TIPC, ...).\nThis resulted in an infoleak reported by KMSAN when the packet was\nreceived:\n\n  =====================================================\n  BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169\n   instrument_copy_to_user ./include/linux/instrumented.h:121\n   copyout+0xbc/0x100 lib/iov_iter.c:169\n   _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527\n   copy_to_iter ./include/linux/uio.h:176\n   simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513\n   __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419\n   skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527\n   skb_copy_datagram_msg ./include/linux/skbuff.h:3903\n   packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469\n   ____sys_recvmsg+0x2c4/0x810 net/socket.c:?\n   ___sys_recvmsg+0x217/0x840 net/socket.c:2743\n   __sys_recvmsg net/socket.c:2773\n   __do_sys_recvmsg net/socket.c:2783\n   __se_sys_recvmsg net/socket.c:2780\n   __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780\n   do_syscall_x64 arch/x86/entry/common.c:50\n   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120\n\n  ...\n\n  Uninit was stored to memory at:\n   tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156\n   tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375\n   tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579\n   tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190\n   tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084\n   tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201\n   __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252\n   __do_sys_setsockopt net/socket.c:2263\n   __se_sys_setsockopt net/socket.c:2260\n   __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260\n   do_syscall_x64 arch/x86/entry/common.c:50\n   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120\n\n  Local variable sub created at:\n   tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562\n   tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190\n\n  Bytes 84-87 of 88 are uninitialized\n  Memory access of size 88 starts at ffff88801ed57cd0\n  Data copied to user address 0000000020000400\n  ...\n  =====================================================(CVE-2022-50531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()\n\nThis patch fixes a shift-out-of-bounds in brcmfmac that occurs in\nBIT(chiprev) when a 'chiprev' provided by the device is too large.\nIt should also not be equal to or greater than BITS_PER_TYPE(u32)\nas we do bitwise AND with a u32 variable and BIT(chiprev). The patch\nadds a check that makes the function return NULL if that is the case.\nNote that the NULL case is later handled by the bus-specific caller,\nbrcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.\n\nFound by a modified version of syzkaller.\n\nUBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c\nshift exponent 151055786 is too large for 64-bit type 'long unsigned int'\nCPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n dump_stack_lvl+0x57/0x7d\n ubsan_epilogue+0x5/0x40\n __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb\n ? lock_chain_count+0x20/0x20\n brcmf_fw_alloc_request.cold+0x19/0x3ea\n ? brcmf_fw_get_firmwares+0x250/0x250\n ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0\n brcmf_usb_get_fwname+0x114/0x1a0\n ? brcmf_usb_reset_resume+0x120/0x120\n ? number+0x6c4/0x9a0\n brcmf_c_process_clm_blob+0x168/0x590\n ? put_dec+0x90/0x90\n ? enable_ptr_key_workfn+0x20/0x20\n ? brcmf_common_pd_remove+0x50/0x50\n ? rcu_read_lock_sched_held+0xa1/0xd0\n brcmf_c_preinit_dcmds+0x673/0xc40\n ? brcmf_c_set_joinpref_default+0x100/0x100\n ? rcu_read_lock_sched_held+0xa1/0xd0\n ? rcu_read_lock_bh_held+0xb0/0xb0\n ? lock_acquire+0x19d/0x4e0\n ? find_held_lock+0x2d/0x110\n ? brcmf_usb_deq+0x1cc/0x260\n ? mark_held_locks+0x9f/0xe0\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n ? _raw_spin_unlock_irqrestore+0x47/0x50\n ? trace_hardirqs_on+0x1c/0x120\n ? brcmf_usb_deq+0x1a7/0x260\n ? brcmf_usb_rx_fill_all+0x5a/0xf0\n brcmf_attach+0x246/0xd40\n ? wiphy_new_nm+0x1476/0x1d50\n ? kmemdup+0x30/0x40\n brcmf_usb_probe+0x12de/0x1690\n ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n usb_probe_interface+0x25f/0x710\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n ? usb_match_id.part.0+0x88/0xc0\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n ? driver_allows_async_probing+0x120/0x120\n bus_for_each_drv+0x123/0x1a0\n ? bus_rescan_devices+0x20/0x20\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n ? trace_hardirqs_on+0x1c/0x120\n __device_attach+0x207/0x330\n ? device_bind_driver+0xb0/0xb0\n ? kobject_uevent_env+0x230/0x12c0\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n ? __mutex_unlock_slowpath+0xe7/0x660\n ? __fw_devlink_link_to_suppliers+0x550/0x550\n usb_set_configuration+0x984/0x1770\n ? kernfs_create_link+0x175/0x230\n usb_generic_driver_probe+0x69/0x90\n usb_probe_device+0x9c/0x220\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n ? driver_allows_async_probing+0x120/0x120\n bus_for_each_drv+0x123/0x1a0\n ? bus_rescan_devices+0x20/0x20\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n ? trace_hardirqs_on+0x1c/0x120\n __device_attach+0x207/0x330\n ? device_bind_driver+0xb0/0xb0\n ? kobject_uevent_env+0x230/0x12c0\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n ? __fw_devlink_link_to_suppliers+0x550/0x550\n usb_new_device.cold+0x463/0xf66\n ? hub_disconnect+0x400/0x400\n ? _raw_spin_unlock_irq+0x24/0x30\n hub_event+0x10d5/0x3330\n ? hub_port_debounce+0x280/0x280\n ? __lock_acquire+0x1671/0x5790\n ? wq_calc_node_cpumask+0x170/0x2a0\n ? lock_release+0x640/0x640\n ? rcu_read_lock_sched_held+0xa1/0xd0\n ? rcu_read_lock_bh_held+0xb0/0xb0\n ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n process_one_work+0x873/0x13e0\n ? lock_release+0x640/0x640\n ? pwq_dec_nr_in_flight+0x320/0x320\n ? rwlock_bug.part.0+0x90/0x90\n worker_thread+0x8b/0xd10\n ? __kthread_parkme+0xd9/0x1d0\n ? pr\n---truncated---(CVE-2022-50551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: use quiesced elevator switch when reinitializing queues\n\nThe hctx's run_work may be racing with the elevator switch when\nreinitializing hardware queues. The queue is merely frozen in this\ncontext, but that only prevents requests from allocating and doesn't\nstop the hctx work from running. The work may get an elevator pointer\nthat's being torn down, and can result in use-after-free errors and\nkernel panics (example below). Use the quiesced elevator switch instead,\nand make the previous one static since it is now only used locally.\n\n  nvme nvme0: resetting controller\n  nvme nvme0: 32/0/0 default/read/poll queues\n  BUG: kernel NULL pointer dereference, address: 0000000000000008\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0\n  Oops: 0000 [#1] SMP PTI\n  Workqueue: kblockd blk_mq_run_work_fn\n  RIP: 0010:kyber_has_work+0x29/0x70\n\n...\n\n  Call Trace:\n   __blk_mq_do_dispatch_sched+0x83/0x2b0\n   __blk_mq_sched_dispatch_requests+0x12e/0x170\n   blk_mq_sched_dispatch_requests+0x30/0x60\n   __blk_mq_run_hw_queue+0x2b/0x50\n   process_one_work+0x1ef/0x380\n   worker_thread+0x2d/0x3e0(CVE-2022-50552)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: don't allow to overwrite ENDPOINT0 attributes\n\nA bad USB device is able to construct a service connection response\nmessage with target endpoint being ENDPOINT0 which is reserved for\nHTC_CTRL_RSVD_SVC and should not be modified to be used for any other\nservices.\n\nReject such service connection responses.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2023-53185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails\n\nSyzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream().\nWhile processing skbs in ath9k_hif_usb_rx_stream(), the already allocated\nskbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If we\nhave an incorrect pkt_len or pkt_tag, the input skb is considered invalid\nand dropped. All the associated packets already in skb_pool should be\ndropped and freed. Added a comment describing this issue.\n\nThe patch also makes remain_skb NULL after being processed so that it\ncannot be referenced after potential free. The initialization of hif_dev\nfields which are associated with remain_skb (rx_remain_len,\nrx_transfer_len and rx_pad_len) is moved after a new remain_skb is\nallocated.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2023-53199)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: bcm_tx_setup(): fix KMSAN uninit-value in vfs_write\n\nSyzkaller reported the following issue:\n\n=====================================================\nBUG: KMSAN: uninit-value in aio_rw_done fs/aio.c:1520 [inline]\nBUG: KMSAN: uninit-value in aio_write+0x899/0x950 fs/aio.c:1600\n aio_rw_done fs/aio.c:1520 [inline]\n aio_write+0x899/0x950 fs/aio.c:1600\n io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019\n __do_sys_io_submit fs/aio.c:2078 [inline]\n __se_sys_io_submit+0x293/0x770 fs/aio.c:2048\n __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:766 [inline]\n slab_alloc_node mm/slub.c:3452 [inline]\n __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491\n __do_kmalloc_node mm/slab_common.c:967 [inline]\n __kmalloc+0x11d/0x3b0 mm/slab_common.c:981\n kmalloc_array include/linux/slab.h:636 [inline]\n bcm_tx_setup+0x80e/0x29d0 net/can/bcm.c:930\n bcm_sendmsg+0x3a2/0xce0 net/can/bcm.c:1351\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg net/socket.c:734 [inline]\n sock_write_iter+0x495/0x5e0 net/socket.c:1108\n call_write_iter include/linux/fs.h:2189 [inline]\n aio_write+0x63a/0x950 fs/aio.c:1600\n io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019\n __do_sys_io_submit fs/aio.c:2078 [inline]\n __se_sys_io_submit+0x293/0x770 fs/aio.c:2048\n __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nCPU: 1 PID: 5034 Comm: syz-executor350 Not tainted 6.2.0-rc6-syzkaller-80422-geda666ff2276 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023\n=====================================================\n\nWe can follow the call chain and find that 'bcm_tx_setup' function\ncalls 'memcpy_from_msg' to copy some content to the newly allocated\nframe of 'op->frames'. After that the 'len' field of copied structure\nbeing compared with some constant value (64 or 8). However, if\n'memcpy_from_msg' returns an error, we will compare some uninitialized\nmemory. This triggers 'uninit-value' issue.\n\nThis patch will add 'memcpy_from_msg' possible errors processing to\navoid uninit-value issue.\n\nTested via syzkaller(CVE-2023-53344)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix warning and UAF when destroy the MR list\n\nIf the MR allocate failed, the MR recovery work not initialized\nand list not cleared. Then will be warning and UAF when release\nthe MR:\n\n  WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110\n  CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82\n  RIP: 0010:__flush_work.isra.0+0xf7/0x110\n  Call Trace:\n   <TASK>\n   __cancel_work_timer+0x2ba/0x2e0\n   smbd_destroy+0x4e1/0x990\n   _smbd_get_connection+0x1cbd/0x2110\n   smbd_get_connection+0x21/0x40\n   cifs_get_tcp_session+0x8ef/0xda0\n   mount_get_conns+0x60/0x750\n   cifs_mount+0x103/0xd00\n   cifs_smb3_do_mount+0x1dd/0xcb0\n   smb3_get_tree+0x1d5/0x300\n   vfs_get_tree+0x41/0xf0\n   path_mount+0x9b3/0xdd0\n   __x64_sys_mount+0x190/0x1d0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n  BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990\n  Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824\n  CPU: 4 PID: 824 Comm: mount.cifs Tainted: G        W          6.1.0-rc5+ #82\n  Call Trace:\n   dump_stack_lvl+0x34/0x44\n   print_report+0x171/0x472\n   kasan_report+0xad/0x130\n   smbd_destroy+0x4fc/0x990\n   _smbd_get_connection+0x1cbd/0x2110\n   smbd_get_connection+0x21/0x40\n   cifs_get_tcp_session+0x8ef/0xda0\n   mount_get_conns+0x60/0x750\n   cifs_mount+0x103/0xd00\n   cifs_smb3_do_mount+0x1dd/0xcb0\n   smb3_get_tree+0x1d5/0x300\n   vfs_get_tree+0x41/0xf0\n   path_mount+0x9b3/0xdd0\n   __x64_sys_mount+0x190/0x1d0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n  Allocated by task 824:\n   kasan_save_stack+0x1e/0x40\n   kasan_set_track+0x21/0x30\n   __kasan_kmalloc+0x7a/0x90\n   _smbd_get_connection+0x1b6f/0x2110\n   smbd_get_connection+0x21/0x40\n   cifs_get_tcp_session+0x8ef/0xda0\n   mount_get_conns+0x60/0x750\n   cifs_mount+0x103/0xd00\n   cifs_smb3_do_mount+0x1dd/0xcb0\n   smb3_get_tree+0x1d5/0x300\n   vfs_get_tree+0x41/0xf0\n   path_mount+0x9b3/0xdd0\n   __x64_sys_mount+0x190/0x1d0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n  Freed by task 824:\n   kasan_save_stack+0x1e/0x40\n   kasan_set_track+0x21/0x30\n   kasan_save_free_info+0x2a/0x40\n   ____kasan_slab_free+0x143/0x1b0\n   __kmem_cache_free+0xc8/0x330\n   _smbd_get_connection+0x1c6a/0x2110\n   smbd_get_connection+0x21/0x40\n   cifs_get_tcp_session+0x8ef/0xda0\n   mount_get_conns+0x60/0x750\n   cifs_mount+0x103/0xd00\n   cifs_smb3_do_mount+0x1dd/0xcb0\n   smb3_get_tree+0x1d5/0x300\n   vfs_get_tree+0x41/0xf0\n   path_mount+0x9b3/0xdd0\n   __x64_sys_mount+0x190/0x1d0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nLet's initialize the MR recovery work before MR allocate to prevent\nthe warning, remove the MRs from the list to prevent the UAF.(CVE-2023-53427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free\n\nStruct pcie_link_state->downstream is a pointer to the pci_dev of function\n0.  Previously we retained that pointer when removing function 0, and\nsubsequent ASPM policy changes dereferenced it, resulting in a\nuse-after-free warning from KASAN, e.g.:\n\n  # echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove\n  # echo powersave > /sys/module/pcie_aspm/parameters/policy\n\n  BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500\n  Call Trace:\n   kasan_report+0xae/0xe0\n   pcie_config_aspm_link+0x42d/0x500\n   pcie_aspm_set_policy+0x8e/0x1a0\n   param_attr_store+0x162/0x2c0\n   module_attr_store+0x3e/0x80\n\nPCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM\nControl value in all functions of multi-function devices.\n\nDisable ASPM and free the pcie_link_state when any child function is\nremoved so we can discard the dangling pcie_link_state->downstream pointer\nand maintain the same ASPM Control configuration for all functions.\n\n[bhelgaas: commit log and comment](CVE-2023-53446)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Correct devm device reference for hidinput input_dev name\n\nReference the HID device rather than the input device for the devm\nallocation of the input_dev name. Referencing the input_dev would lead to a\nuse-after-free when the input_dev was unregistered and subsequently fires a\nuevent that depends on the name. At the point of firing the uevent, the\nname would be freed by devres management.\n\nUse devm_kasprintf to simplify the logic for allocating memory and\nformatting the input_dev name string.(CVE-2023-53454)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: fix slab-use-after-free in decode_session6\n\nWhen the xfrm device is set to the qdisc of the sfb type, the cb field\nof the sent skb may be modified during enqueuing. Then,\nslab-use-after-free may occur when the xfrm device sends IPv6 packets.\n\nThe stack information is as follows:\nBUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890\nRead of size 1 at addr ffff8881111458ef by task swapper/3/0\nCPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014\nCall Trace:\n<IRQ>\ndump_stack_lvl+0xd9/0x150\nprint_address_description.constprop.0+0x2c/0x3c0\nkasan_report+0x11d/0x130\ndecode_session6+0x103f/0x1890\n__xfrm_decode_session+0x54/0xb0\nxfrmi_xmit+0x173/0x1ca0\ndev_hard_start_xmit+0x187/0x700\nsch_direct_xmit+0x1a3/0xc30\n__qdisc_run+0x510/0x17a0\n__dev_queue_xmit+0x2215/0x3b10\nneigh_connected_output+0x3c2/0x550\nip6_finish_output2+0x55a/0x1550\nip6_finish_output+0x6b9/0x1270\nip6_output+0x1f1/0x540\nndisc_send_skb+0xa63/0x1890\nndisc_send_rs+0x132/0x6f0\naddrconf_rs_timer+0x3f1/0x870\ncall_timer_fn+0x1a0/0x580\nexpire_timers+0x29b/0x4b0\nrun_timer_softirq+0x326/0x910\n__do_softirq+0x1d4/0x905\nirq_exit_rcu+0xb7/0x120\nsysvec_apic_timer_interrupt+0x97/0xc0\n</IRQ>\n<TASK>\nasm_sysvec_apic_timer_interrupt+0x1a/0x20\nRIP: 0010:intel_idle_hlt+0x23/0x30\nCode: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 <fa> 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4\nRSP: 0018:ffffc90000197d78 EFLAGS: 00000246\nRAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5\nRDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50\nRBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d\nR10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001\nR13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000\ncpuidle_enter_state+0xd3/0x6f0\ncpuidle_enter+0x4e/0xa0\ndo_idle+0x2fe/0x3c0\ncpu_startup_entry+0x18/0x20\nstart_secondary+0x200/0x290\nsecondary_startup_64_no_verify+0x167/0x16b\n</TASK>\nAllocated by task 939:\nkasan_save_stack+0x22/0x40\nkasan_set_track+0x25/0x30\n__kasan_slab_alloc+0x7f/0x90\nkmem_cache_alloc_node+0x1cd/0x410\nkmalloc_reserve+0x165/0x270\n__alloc_skb+0x129/0x330\ninet6_ifa_notify+0x118/0x230\n__ipv6_ifa_notify+0x177/0xbe0\naddrconf_dad_completed+0x133/0xe00\naddrconf_dad_work+0x764/0x1390\nprocess_one_work+0xa32/0x16f0\nworker_thread+0x67d/0x10c0\nkthread+0x344/0x440\nret_from_fork+0x1f/0x30\nThe buggy address belongs to the object at ffff888111145800\nwhich belongs to the cache skbuff_small_head of size 640\nThe buggy address is located 239 bytes inside of\nfreed 640-byte region [ffff888111145800, ffff888111145a80)\n\nAs commit f855691975bb ("xfrm6: Fix the nexthdr offset in\n_decode_session6.") showed, xfrm_decode_session was originally intended\nonly for the receive path. IP6CB(skb)->nhoff is not set during\ntransmission. Therefore, set the cb field in the skb to 0 before\nsending packets.(CVE-2023-53500)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds\n\nFix a stack-out-of-bounds read in brcmfmac that occurs\nwhen 'buf' that is not null-terminated is passed as an argument of\nstrreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with\na CLM version string by memcpy() in brcmf_fil_iovar_data_get().\nEnsure buf is null-terminated.\n\nFound by a modified version of syzkaller.\n\n[   33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available\n[   33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22\n[   33.021554][ T1896] ==================================================================\n[   33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110\n[   33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896\n[   33.023852][ T1896]\n[   33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132\n[   33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\n[   33.026065][ T1896] Workqueue: usb_hub_wq hub_event\n[   33.026581][ T1896] Call Trace:\n[   33.026896][ T1896]  dump_stack_lvl+0x57/0x7d\n[   33.027372][ T1896]  print_address_description.constprop.0.cold+0xf/0x334\n[   33.028037][ T1896]  ? strreplace+0xf2/0x110\n[   33.028403][ T1896]  ? strreplace+0xf2/0x110\n[   33.028807][ T1896]  kasan_report.cold+0x83/0xdf\n[   33.029283][ T1896]  ? strreplace+0xf2/0x110\n[   33.029666][ T1896]  strreplace+0xf2/0x110\n[   33.029966][ T1896]  brcmf_c_preinit_dcmds+0xab1/0xc40\n[   33.030351][ T1896]  ? brcmf_c_set_joinpref_default+0x100/0x100\n[   33.030787][ T1896]  ? rcu_read_lock_sched_held+0xa1/0xd0\n[   33.031223][ T1896]  ? rcu_read_lock_bh_held+0xb0/0xb0\n[   33.031661][ T1896]  ? lock_acquire+0x19d/0x4e0\n[   33.032091][ T1896]  ? find_held_lock+0x2d/0x110\n[   33.032605][ T1896]  ? brcmf_usb_deq+0x1a7/0x260\n[   33.033087][ T1896]  ? brcmf_usb_rx_fill_all+0x5a/0xf0\n[   33.033582][ T1896]  brcmf_attach+0x246/0xd40\n[   33.034022][ T1896]  ? wiphy_new_nm+0x1476/0x1d50\n[   33.034383][ T1896]  ? kmemdup+0x30/0x40\n[   33.034722][ T1896]  brcmf_usb_probe+0x12de/0x1690\n[   33.035223][ T1896]  ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n[   33.035833][ T1896]  usb_probe_interface+0x25f/0x710\n[   33.036315][ T1896]  really_probe+0x1be/0xa90\n[   33.036656][ T1896]  __driver_probe_device+0x2ab/0x460\n[   33.037026][ T1896]  ? usb_match_id.part.0+0x88/0xc0\n[   33.037383][ T1896]  driver_probe_device+0x49/0x120\n[   33.037790][ T1896]  __device_attach_driver+0x18a/0x250\n[   33.038300][ T1896]  ? driver_allows_async_probing+0x120/0x120\n[   33.038986][ T1896]  bus_for_each_drv+0x123/0x1a0\n[   33.039906][ T1896]  ? bus_rescan_devices+0x20/0x20\n[   33.041412][ T1896]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n[   33.041861][ T1896]  ? trace_hardirqs_on+0x1c/0x120\n[   33.042330][ T1896]  __device_attach+0x207/0x330\n[   33.042664][ T1896]  ? device_bind_driver+0xb0/0xb0\n[   33.043026][ T1896]  ? kobject_uevent_env+0x230/0x12c0\n[   33.043515][ T1896]  bus_probe_device+0x1a2/0x260\n[   33.043914][ T1896]  device_add+0xa61/0x1ce0\n[   33.044227][ T1896]  ? __mutex_unlock_slowpath+0xe7/0x660\n[   33.044891][ T1896]  ? __fw_devlink_link_to_suppliers+0x550/0x550\n[   33.045531][ T1896]  usb_set_configuration+0x984/0x1770\n[   33.046051][ T1896]  ? kernfs_create_link+0x175/0x230\n[   33.046548][ T1896]  usb_generic_driver_probe+0x69/0x90\n[   33.046931][ T1896]  usb_probe_device+0x9c/0x220\n[   33.047434][ T1896]  really_probe+0x1be/0xa90\n[   33.047760][ T1896]  __driver_probe_device+0x2ab/0x460\n[   33.048134][ T1896]  driver_probe_device+0x49/0x120\n[   33.048516][ T1896]  __device_attach_driver+0x18a/0x250\n[   33.048910][ T1896]  ? driver_allows_async_probing+0x120/0x120\n---truncated---(CVE-2023-53582)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: hif_usb: fix memory leak of remain_skbs\n\nhif_dev->remain_skb is allocated and used exclusively in\nath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is\nprocessed and subsequently freed (in error paths) only during the next\ncall of ath9k_hif_usb_rx_stream().\n\nSo, if the urbs are deallocated between those two calls due to the device\ndeinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()\nis not called next time and the allocated remain_skb is leaked. Our local\nSyzkaller instance was able to trigger that.\n\nremain_skb makes sense when receiving two consecutive urbs which are\nlogically linked together, i.e. a specific data field from the first skb\nindicates a cached skb to be allocated, memcpy'd with some data and\nsubsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs\ndeallocation supposedly makes that link irrelevant so we need to free the\ncached skb in those cases.\n\nFix the leak by introducing a function to explicitly free remain_skb (if\nit is not NULL) when the rx urbs have been deallocated. remain_skb is NULL\nwhen it has not been allocated at all (hif_dev struct is kzalloced) or\nwhen it has been processed in next call to ath9k_hif_usb_rx_stream().\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2023-53641)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix possible desc_ptr out-of-bounds accesses\n\nSanitize possible desc_ptr out-of-bounds accesses in\nses_enclosure_data_process().(CVE-2023-53675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()\n\nThe function lio_target_nacl_info_show() uses sprintf() in a loop to print\ndetails for every iSCSI connection in a session without checking for the\nbuffer length. With enough iSCSI connections it's possible to overflow the\nbuffer provided by configfs and corrupt the memory.\n\nThis patch replaces sprintf() with sysfs_emit_at() that checks for buffer\nboundries.(CVE-2023-53676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()\n\nFix a stack-out-of-bounds write that occurs in a WMI response callback\nfunction that is called after a timeout occurs in ath9k_wmi_cmd().\nThe callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer that\ncould no longer be valid when a timeout occurs. Set wmi->last_seq_id to\n0 when a timeout occurred.\n\nFound by a modified version of syzkaller.\n\nBUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rx\nWrite of size 4\nCall Trace:\n memcpy\n ath9k_wmi_ctrl_rx\n ath9k_htc_rx_msg\n ath9k_hif_usb_reg_in_cb\n __usb_hcd_giveback_urb\n usb_hcd_giveback_urb\n dummy_timer\n call_timer_fn\n run_timer_softirq\n __do_softirq\n irq_exit_rcu\n sysvec_apic_timer_interrupt(CVE-2023-53717)\n\nIn the Linux kernel, a resource management vulnerability exists in the cls_u32 network scheduler component. When the u32_replace_hw_knode operation fails, the system fails to properly undo the tcf_bind_filter operation previously performed via u32_set_parms, potentially leading to resource leaks or privilege escalation.(CVE-2023-53733)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan't be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn't in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --> trigger BUG_ON due to\n  unmap_poisoned_folio couldn't\n   handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.(CVE-2025-39782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: udf: fix OOB read in lengthAllocDescs handling\n\nWhen parsing Allocation Extent Descriptor, lengthAllocDescs comes from\non-disk data and must be validated against the block size. Crafted or\ncorrupted images may set lengthAllocDescs so that the total descriptor\nlength (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,\nleading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and\ntrigger a KASAN use-after-free read.\n\nBUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60\nRead of size 1 at addr ffff888041e7d000 by task syz-executor317/5309\n\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60\n udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261\n udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179\n extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46\n udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106\n udf_release_file+0xc1/0x120 fs/udf/file.c:185\n __fput+0x23f/0x880 fs/file_table.c:431\n task_work_run+0x24f/0x310 kernel/task_work.c:239\n exit_task_work include/linux/task_work.h:43 [inline]\n do_exit+0xa2f/0x28e0 kernel/exit.c:939\n do_group_exit+0x207/0x2c0 kernel/exit.c:1088\n __do_sys_exit_group kernel/exit.c:1099 [inline]\n __se_sys_exit_group kernel/exit.c:1097 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097\n x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n </TASK>\n\nValidate the computed total length against epos->bh->b_size.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-40044)","modified":"2026-03-11T07:14:00.667501Z","published":"2025-11-14T12:38:43Z","upstream":["CVE-2022-50349","CVE-2022-50352","CVE-2022-50435","CVE-2022-50482","CVE-2022-50484","CVE-2022-50489","CVE-2022-50520","CVE-2022-50531","CVE-2022-50551","CVE-2022-50552","CVE-2023-53185","CVE-2023-53199","CVE-2023-53344","CVE-2023-53427","CVE-2023-53446","CVE-2023-53454","CVE-2023-53500","CVE-2023-53582","CVE-2023-53641","CVE-2023-53675","CVE-2023-53676","CVE-2023-53717","CVE-2023-53733","CVE-2025-39725","CVE-2025-39782","CVE-2025-39973","CVE-2025-40044"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2659"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50349"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50352"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50435"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50482"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50484"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50489"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50520"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50531"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50551"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50552"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53185"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53199"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53344"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53427"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53446"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53454"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53500"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53582"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53641"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53675"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53676"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53717"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53733"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39725"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39782"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39973"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40044"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:20.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2511.2.0.0351.oe2003sp4"}]}],"ecosystem_specific":{"x86_64":["bpftool-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","kernel-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","perf-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.x86_64.rpm"],"src":["kernel-4.19.90-2511.2.0.0351.oe2003sp4.src.rpm"],"aarch64":["bpftool-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","kernel-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","perf-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2511.2.0.0351.oe2003sp4.aarch64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2025-2659.json"}}],"schema_version":"1.7.5"}