{"id":"OESA-2026-2418","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:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL.  So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS:  00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: <TASK> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[akpm@linux-foundation.org: add unlikely()](CVE-2024-56611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI/MSI: Handle lack of irqdomain gracefully\n\nAlexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a\nRISCV platform which does not provide PCI/MSI support:\n\n WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32\n __pci_enable_msix_range+0x30c/0x596\n pci_msi_setup_msi_irqs+0x2c/0x32\n pci_alloc_irq_vectors_affinity+0xb8/0xe2\n\nRISCV uses hierarchical interrupt domains and correctly does not implement\nthe legacy fallback. The warning triggers from the legacy fallback stub.\n\nThat warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent\ndomain is associated with the device or not. There is a check for MSI-X,\nwhich has a legacy assumption. But that legacy fallback assumption is only\nvalid when legacy support is enabled, but otherwise the check should simply\nreturn -ENOTSUPP.\n\nLoongarch tripped over the same problem and blindly enabled legacy support\nwithout implementing the legacy fallbacks. There are weak implementations\nwhich return an error, so the problem was papered over.\n\nCorrect pci_msi_domain_supports() to evaluate the legacy mode and add\nthe missing supported check into the MSI enable path to complete it.(CVE-2024-56760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: fix nfs_release_folio() to not deadlock via kcompactd writeback\n\nAdd PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so\nnfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.\n\nOtherwise NFS can deadlock waiting for kcompactd enduced writeback which\nrecurses back to NFS (which triggers writeback to NFSD via NFS loopback\nmount on the same host, NFSD blocks waiting for XFS's call to\n__filemap_get_folio):\n\n6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.\n\n{---\n[58] "kcompactd0"\n[<0>] folio_wait_bit+0xe8/0x200\n[<0>] folio_wait_writeback+0x2b/0x80\n[<0>] nfs_wb_folio+0x80/0x1b0 [nfs]\n[<0>] nfs_release_folio+0x68/0x130 [nfs]\n[<0>] split_huge_page_to_list_to_order+0x362/0x840\n[<0>] migrate_pages_batch+0x43d/0xb90\n[<0>] migrate_pages_sync+0x9a/0x240\n[<0>] migrate_pages+0x93c/0x9f0\n[<0>] compact_zone+0x8e2/0x1030\n[<0>] compact_node+0xdb/0x120\n[<0>] kcompactd+0x121/0x2e0\n[<0>] kthread+0xcf/0x100\n[<0>] ret_from_fork+0x31/0x40\n[<0>] ret_from_fork_asm+0x1a/0x30\n---}\n\n[(CVE-2025-21908)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio\n\nCommit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to\nbe offlined) add page poison checks in do_migrate_range in order to make\noffline hwpoisoned page possible by introducing isolate_lru_page and\ntry_to_unmap for hwpoisoned page.  However folio lock must be held before\ncalling try_to_unmap.  Add it to fix this problem.\n\nWarning will be produced if folio is not locked during unmap:\n\n  ------------[ cut here ]------------\n  kernel BUG at ./include/linux/swapops.h:400!\n  Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n  Modules linked in:\n  CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G        W          6.13.0-rc1-00016-g3c434c7ee82a-dirty #41\n  Tainted: [W]=WARN\n  Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015\n  pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : try_to_unmap_one+0xb08/0xd3c\n  lr : try_to_unmap_one+0x3dc/0xd3c\n  Call trace:\n   try_to_unmap_one+0xb08/0xd3c (P)\n   try_to_unmap_one+0x3dc/0xd3c (L)\n   rmap_walk_anon+0xdc/0x1f8\n   rmap_walk+0x3c/0x58\n   try_to_unmap+0x88/0x90\n   unmap_poisoned_folio+0x30/0xa8\n   do_migrate_range+0x4a0/0x568\n   offline_pages+0x5a4/0x670\n   memory_block_action+0x17c/0x374\n   memory_subsys_offline+0x3c/0x78\n   device_offline+0xa4/0xd0\n   state_store+0x8c/0xf0\n   dev_attr_store+0x18/0x2c\n   sysfs_kf_write+0x44/0x54\n   kernfs_fop_write_iter+0x118/0x1a8\n   vfs_write+0x3a8/0x4bc\n   ksys_write+0x6c/0xf8\n   __arm64_sys_write+0x1c/0x28\n   invoke_syscall+0x44/0x100\n   el0_svc_common.constprop.0+0x40/0xe0\n   do_el0_svc+0x1c/0x28\n   el0_svc+0x30/0xd0\n   el0t_64_sync_handler+0xc8/0xcc\n   el0t_64_sync+0x198/0x19c\n  Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000)\n  ---[ end trace 0000000000000000 ]---(CVE-2025-21931)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Bridge, fix the crash caused by LAG state check\n\nWhen removing LAG device from bridge, NETDEV_CHANGEUPPER event is\ntriggered. Driver finds the lower devices (PFs) to flush all the\noffloaded entries. And mlx5_lag_is_shared_fdb is checked, it returns\nfalse if one of PF is unloaded. In such case,\nmlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead of\nthe alive PF, and the flush is skipped.\n\nBesides, the bridge fdb entry's lastuse is updated in mlx5 bridge\nevent handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can be\nignored in this case because the upper interface for bond is deleted,\nand the entry will never be aged because lastuse is never updated.\n\nTo make things worse, as the entry is alive, mlx5 bridge workqueue\nkeeps sending that event, which is then handled by kernel bridge\nnotifier. It causes the following crash when accessing the passed bond\nnetdev which is already destroyed.\n\nTo fix this issue, remove such checks. LAG state is already checked in\ncommit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when adding\nbond to bridge"), driver still need to skip offload if LAG becomes\ninvalid state after initialization.\n\n Oops: stack segment: 0000 [#1] SMP\n CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G           OE      6.11.0_mlnx #1\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core]\n RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge]\n Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7\n RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297\n RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff\n RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0\n RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8\n R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60\n R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000\n FS:  0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n  <TASK>\n  ? __die_body+0x1a/0x60\n  ? die+0x38/0x60\n  ? do_trap+0x10b/0x120\n  ? do_error_trap+0x64/0xa0\n  ? exc_stack_segment+0x33/0x50\n  ? asm_exc_stack_segment+0x22/0x30\n  ? br_switchdev_event+0x2c/0x110 [bridge]\n  ? sched_balance_newidle.isra.149+0x248/0x390\n  notifier_call_chain+0x4b/0xa0\n  atomic_notifier_call_chain+0x16/0x20\n  mlx5_esw_bridge_update+0xec/0x170 [mlx5_core]\n  mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core]\n  process_scheduled_works+0x81/0x390\n  worker_thread+0x106/0x250\n  ? bh_worker+0x110/0x110\n  kthread+0xb7/0xe0\n  ? kthread_park+0x80/0x80\n  ret_from_fork+0x2d/0x50\n  ? kthread_park+0x80/0x80\n  ret_from_fork_asm+0x11/0x20\n  </TASK>(CVE-2025-21970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: Prevent creation of classes with TC_H_ROOT\n\nThe function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination\ncondition when traversing up the qdisc tree to update parent backlog\ncounters. However, if a class is created with classid TC_H_ROOT, the\ntraversal terminates prematurely at this class instead of reaching the\nactual root qdisc, causing parent statistics to be incorrectly maintained.\nIn case of DRR, this could lead to a crash as reported by Mingi Cho.\n\nPrevent the creation of any Qdisc class with classid TC_H_ROOT\n(0xFFFFFFFF) across all qdisc types, as suggested by Jamal.(CVE-2025-21971)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: address a potential NULL pointer dereference in the GRED scheduler.\n\nIf kzalloc in gred_init returns a NULL pointer, the code follows the\nerror handling path, invoking gred_destroy. This, in turn, calls\ngred_offload, where memset could receive a NULL pointer as input,\npotentially leading to a kernel crash.\n\nWhen table->opt is NULL in gred_init(), gred_change_table_def()\nis not called yet, so it is not necessary to call ->ndo_setup_tc()\nin gred_offload().(CVE-2025-21980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix memory leak in aRFS after reset\n\nFix aRFS (accelerated Receive Flow Steering) structures memory leak by\nadding a checker to verify if aRFS memory is already allocated while\nconfiguring VSI. aRFS objects are allocated in two cases:\n- as part of VSI initialization (at probe), and\n- as part of reset handling\n\nHowever, VSI reconfiguration executed during reset involves memory\nallocation one more time, without prior releasing already allocated\nresources. This led to the memory leak with the following signature:\n\n[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak\nunreferenced object 0xff3c1ca7252e6000 (size 8192):\n  comm "kworker/0:0", pid 8, jiffies 4296833052\n  hex dump (first 32 bytes):\n    00 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 0):\n    [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340\n    [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice]\n    [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice]\n    [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice]\n    [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice]\n    [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice]\n    [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0\n    [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20\n    [<ffffffff98f0b6d9>] process_one_work+0x179/0x390\n    [<ffffffff98f0c1e9>] worker_thread+0x239/0x340\n    [<ffffffff98f14abc>] kthread+0xcc/0x100\n    [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50\n    [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30\n    ...(CVE-2025-21981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: switchdev: Convert blocking notification chain to a raw one\n\nA blocking notification chain uses a read-write semaphore to protect the\nintegrity of the chain. The semaphore is acquired for writing when\nadding / removing notifiers to / from the chain and acquired for reading\nwhen traversing the chain and informing notifiers about an event.\n\nIn case of the blocking switchdev notification chain, recursive\nnotifications are possible which leads to the semaphore being acquired\ntwice for reading and to lockdep warnings being generated [1].\n\nSpecifically, this can happen when the bridge driver processes a\nSWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications\nabout deferred events when calling switchdev_deferred_process().\n\nFix this by converting the notification chain to a raw notification\nchain in a similar fashion to the netdev notification chain. Protect\nthe chain using the RTNL mutex by acquiring it when modifying the chain.\nEvents are always informed under the RTNL mutex, but add an assertion in\ncall_switchdev_blocking_notifiers() to make sure this is not violated in\nthe future.\n\nMaintain the "blocking" prefix as events are always emitted from process\ncontext and listeners are allowed to block.\n\n[1]:\nWARNING: possible recursive locking detected\n6.14.0-rc4-custom-g079270089484 #1 Not tainted\n--------------------------------------------\nip/52731 is trying to acquire lock:\nffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0\n\nbut task is already holding lock:\nffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0\n\nother info that might help us debug this:\nPossible unsafe locking scenario:\nCPU0\n----\nlock((switchdev_blocking_notif_chain).rwsem);\nlock((switchdev_blocking_notif_chain).rwsem);\n\n*** DEADLOCK ***\nMay be due to missing lock nesting notation\n3 locks held by ip/52731:\n #0: ffffffff84f795b0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x727/0x1dc0\n #1: ffffffff8731f628 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x790/0x1dc0\n #2: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0\n\nstack backtrace:\n...\n? __pfx_down_read+0x10/0x10\n? __pfx_mark_lock+0x10/0x10\n? __pfx_switchdev_port_attr_set_deferred+0x10/0x10\nblocking_notifier_call_chain+0x58/0xa0\nswitchdev_port_attr_notify.constprop.0+0xb3/0x1b0\n? __pfx_switchdev_port_attr_notify.constprop.0+0x10/0x10\n? mark_held_locks+0x94/0xe0\n? switchdev_deferred_process+0x11a/0x340\nswitchdev_port_attr_set_deferred+0x27/0xd0\nswitchdev_deferred_process+0x164/0x340\nbr_switchdev_port_unoffload+0xc8/0x100 [bridge]\nbr_switchdev_blocking_event+0x29f/0x580 [bridge]\nnotifier_call_chain+0xa2/0x440\nblocking_notifier_call_chain+0x6e/0xa0\nswitchdev_bridge_port_unoffload+0xde/0x1a0\n...(CVE-2025-21986)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sched: Fix fence reference count leak\n\nThe last_scheduled fence leaks when an entity is being killed and adding\nthe cleanup callback fails.\n\nDecrement the reference count of prev when dma_fence_add_callback()\nfails, ensuring proper balance.\n\n[phasta: add git tag info for stable kernel](CVE-2025-21995)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naccel/qaic: Fix integer overflow in qaic_validate_req()\n\nThese are u64 variables that come from the user via\nqaic_attach_slice_bo_ioctl().  Use check_add_overflow() to ensure that\nthe math doesn't have an integer wrapping bug.(CVE-2025-22001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: dummy: force synchronous probing\n\nSometimes I get a NULL pointer dereference at boot time in kobject_get()\nwith the following call stack:\n\nanatop_regulator_probe()\n devm_regulator_register()\n  regulator_register()\n   regulator_resolve_supply()\n    kobject_get()\n\nBy placing some extra BUG_ON() statements I could verify that this is\nraised because probing of the 'dummy' regulator driver is not completed\n('dummy_regulator_rdev' is still NULL).\n\nIn the JTAG debugger I can see that dummy_regulator_probe() and\nanatop_regulator_probe() can be run by different kernel threads\n(kworker/u4:*).  I haven't further investigated whether this can be\nchanged or if there are other possibilities to force synchronization\nbetween these two probe routines.  On the other hand I don't expect much\nboot time penalty by probing the 'dummy' regulator synchronously.(CVE-2025-22009)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspufs: fix a leak in spufs_create_context()\n\nLeak fixes back in 2008 missed one case - if we are trying to set affinity\nand spufs_mkdir() fails, we need to drop the reference to neighbor.(CVE-2025-22071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert "smb: client: fix TCP timers deadlock after rmmod"\n\nThis reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.\n\nCommit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after\nrmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is\nmentioned as CVE-2024-54680, but is actually did not fix anything;\nThe issue can be reproduced on top of it. [0]\n\nAlso, it reverted the change by commit ef7134c7fc48 ("smb: client:\nFix use-after-free of network namespace.") and introduced a real\nissue by reviving the kernel TCP socket.\n\nWhen a reconnect happens for a CIFS connection, the socket state\ntransitions to FIN_WAIT_1.  Then, inet_csk_clear_xmit_timers_sync()\nin tcp_close() stops all timers for the socket.\n\nIf an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1\nforever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.\n\nUsually, FIN can be retransmitted by the peer, but if the peer aborts\nthe connection, the issue comes into reality.\n\nI warned about this privately by pointing out the exact report [1],\nbut the bogus fix was finally merged.\n\nSo, we should not stop the timers to finally kill the connection on\nour side in that case, meaning we must not use a kernel socket for\nTCP whose sk->sk_net_refcnt is 0.\n\nThe kernel socket does not have a reference to its netns to make it\npossible to tear down netns without cleaning up every resource in it.\n\nFor example, tunnel devices use a UDP socket internally, but we can\ndestroy netns without removing such devices and let it complete\nduring exit.  Otherwise, netns would be leaked when the last application\ndied.\n\nHowever, this is problematic for TCP sockets because TCP has timers to\nclose the connection gracefully even after the socket is close()d.  The\nlifetime of the socket and its netns is different from the lifetime of\nthe underlying connection.\n\nIf the socket user does not maintain the netns lifetime, the timer could\nbe fired after the socket is close()d and its netns is freed up, resulting\nin use-after-free.\n\nActually, we have seen so many similar issues and converted such sockets\nto have a reference to netns.\n\nThat's why I converted the CIFS client socket to have a reference to\nnetns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope\nof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right\nfix**.\n\nRegarding the LOCKDEP issue, we can prevent the module unload by\nbumping the module refcount when switching the LOCKDDEP key in\nsock_lock_init_class_and_name(). [2]\n\nFor a while, let's revert the bogus fix.\n\nNote that now we can use sk_net_refcnt_upgrade() for the socket\nconversion, but I'll do so later separately to make backport easy.(CVE-2025-22077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: fix pipe accounting mismatch\n\nCurrently, watch_queue_set_size() modifies the pipe buffers charged to\nuser->pipe_bufs without updating the pipe->nr_accounted on the pipe\nitself, due to the if (!pipe_has_watch_queue()) test in\npipe_resize_ring(). This means that when the pipe is ultimately freed,\nwe decrement user->pipe_bufs by something other than what than we had\ncharged to it, potentially leading to an underflow. This in turn can\ncause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.\n\nTo remedy this, explicitly account for the pipe usage in\nwatch_queue_set_size() to match the number set via account_pipe_buffers()\n\n(It's unclear why watch_queue_set_size() does not update nr_accounted;\nit may be due to intentional overprovisioning in watch_queue_set_size()?)(CVE-2025-23138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi_parser: add check to avoid out of bound access\n\nThere is a possibility that init_codecs is invoked multiple times during\nmanipulated payload from video firmware. In such case, if codecs_count\ncan get incremented to value more than MAX_CODEC_NUM, there can be OOB\naccess. Reset the count so that it always starts from beginning.(CVE-2025-23157)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add sanity check for agwidth in dbMount\n\nThe width in dmapctl of the AG is zero, it trigger a divide error when\ncalculating the control page level in dbAllocAG.\n\nTo avoid this issue, add a check for agwidth in dbAllocAG.(CVE-2025-37740)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group\n\nCurrently, mtk_iommu calls during probe iommu_device_register before\nthe hw_list from driver data is initialized. Since iommu probing issue\nfix, it leads to NULL pointer dereference in mtk_iommu_device_group when\nhw_list is accessed with list_first_entry (not null safe).\n\nSo, change the call order to ensure iommu_device_register is called\nafter the driver data are initialized.(CVE-2025-37748)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37766)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37768)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37770)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37771)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix dangling pointer in krb_authenticate\n\nkrb_authenticate frees sess->user and does not set the pointer\nto NULL. It calls ksmbd_krb5_authenticate to reinitialise\nsess->user but that function may return without doing so. If\nthat happens then smb2_sess_setup, which calls krb_authenticate,\nwill be accessing free'd memory when it later uses sess->user.(CVE-2025-37778)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\navs_component_probe() does not check for this case, which results in a\nNULL pointer dereference.(CVE-2025-37793)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsound/virtio: Fix cancel_sync warnings on uninitialized work_structs\n\nBetty reported hitting the following warning:\n\n[    8.709131][  T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182\n...\n[    8.713282][  T221] Call trace:\n[    8.713365][  T221]  __flush_work+0x8d0/0x914\n[    8.713468][  T221]  __cancel_work_sync+0xac/0xfc\n[    8.713570][  T221]  cancel_work_sync+0x24/0x34\n[    8.713667][  T221]  virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]\n[    8.713868][  T221]  virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]\n[    8.714035][  T221]  virtio_dev_probe+0x28c/0x390\n[    8.714139][  T221]  really_probe+0x1bc/0x4c8\n...\n\nIt seems we're hitting the error path in virtsnd_probe(), which\ntriggers a virtsnd_remove() which iterates over the substreams\ncalling cancel_work_sync() on the elapsed_period work_struct.\n\nLooking at the code, from earlier in:\nvirtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg()\n\nWe set snd->nsubstreams, allocate the snd->substreams, and if\nwe then hit an error on the info allocation or something in\nvirtsnd_ctl_query_info() fails, we will exit without having\ninitialized the elapsed_period work_struct.\n\nWhen that error path unwinds we then call virtsnd_remove()\nwhich as long as the substreams array is allocated, will iterate\nthrough calling cancel_work_sync() on the uninitialized work\nstruct hitting this warning.\n\nTakashi Iwai suggested this fix, which initializes the substreams\nstructure right after allocation, so that if we hit the error\npaths we avoid trying to cleanup uninitialized data.\n\nNote: I have not yet managed to reproduce the issue myself, so\nthis patch has had limited testing.\n\nFeedback or thoughts would be appreciated!(CVE-2025-37805)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration\n\nResolve kernel panic while accessing IRQ handler associated with the\ngenerated IRQ. This is done by acquiring the spinlock and storing the\ncurrent interrupt state before handling the interrupt request using\ngeneric_handle_irq.\n\nA previous fix patch was submitted where 'generic_handle_irq' was\nreplaced with 'handle_nested_irq'. However, this change also causes\nthe kernel panic where after determining which GPIO triggered the\ninterrupt and attempting to call handle_nested_irq with the mapped\nIRQ number, leads to a failure in locating the registered handler.(CVE-2025-37815)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy->cpus mask. apple_soc_cpufreq_get_rate() does not check\nfor this case, which results in a NULL pointer dereference.(CVE-2025-37831)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: avoid NULL pointer dereference in dbg call\n\ncifs_server_dbg() implies server to be non-NULL so\nmove call under condition to avoid NULL pointer dereference.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37844)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: debugfs hang_hws skip GPU with MES\n\ndebugfs hang_hws is used by GPU reset test with HWS, for MES this crash\nthe kernel with NULL pointer access because dqm->packet_mgr is not setup\nfor MES path.\n\nSkip GPU with MES for now, MES hang_hws debugfs interface will be\nsupported later.(CVE-2025-37853)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()\n\nThe variable d->name, returned by devm_kasprintf(), could be NULL.\nA pointer check is added to prevent potential NULL pointer dereference.\nThis is similar to the fix in commit 3027e7b15b02\n("ice: Fix some null pointer dereference issues in ice_ptp.c").\n\nThis issue is found by our static analysis tool(CVE-2025-37881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: ops: Consistently treat platform_max as control value\n\nThis reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in\nsnd_soc_put_volsw() by +min"), and makes some additional related\nupdates.\n\nThere are two ways the platform_max could be interpreted; the maximum\nregister value, or the maximum value the control can be set to. The\npatch moved from treating the value as a control value to a register\none. When the patch was applied it was technically correct as\nsnd_soc_limit_volume() also used the register interpretation. However,\neven then most of the other usages treated platform_max as a\ncontrol value, and snd_soc_limit_volume() has since been updated to\nalso do so in commit fb9ad24485087 ("ASoC: ops: add correct range\ncheck for limiting volume"). That patch however, missed updating\nsnd_soc_put_volsw() back to the control interpretation, and fixing\nsnd_soc_info_volsw_range(). The control interpretation makes more\nsense as limiting is typically done from the machine driver, so it is\nappropriate to use the customer facing representation rather than the\ninternal codec representation. Update all the code to consistently use\nthis interpretation of platform_max.\n\nFinally, also add some comments to the soc_mixer_control struct to\nhopefully avoid further patches switching between the two approaches.(CVE-2025-37889)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_scmi: Balance device refcount when destroying devices\n\nUsing device_find_child() to lookup the proper SCMI device to destroy\ncauses an unbalance in device refcount, since device_find_child() calls an\nimplicit get_device(): this, in turns, inhibits the call of the provided\nrelease methods upon devices destruction.\n\nAs a consequence, one of the structures that is not freed properly upon\ndestruction is the internal struct device_private dev->p populated by the\ndrivers subsystem core.\n\nKMemleak detects this situation since loading/unloding some SCMI driver\ncauses related devices to be created/destroyed without calling any\ndevice_release method.\n\nunreferenced object 0xffff00000f583800 (size 512):\n  comm "insmod", pid 227, jiffies 4294912190\n  hex dump (first 32 bytes):\n    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........\n    ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff  ........`6......\n  backtrace (crc 114e2eed):\n    kmemleak_alloc+0xbc/0xd8\n    __kmalloc_cache_noprof+0x2dc/0x398\n    device_add+0x954/0x12d0\n    device_register+0x28/0x40\n    __scmi_device_create.part.0+0x1bc/0x380\n    scmi_device_create+0x2d0/0x390\n    scmi_create_protocol_devices+0x74/0xf8\n    scmi_device_request_notifier+0x1f8/0x2a8\n    notifier_call_chain+0x110/0x3b0\n    blocking_notifier_call_chain+0x70/0xb0\n    scmi_driver_register+0x350/0x7f0\n    0xffff80000a3b3038\n    do_one_initcall+0x12c/0x730\n    do_init_module+0x1dc/0x640\n    load_module+0x4b20/0x5b70\n    init_module_from_file+0xec/0x158\n\n$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0\ndevice_add+0x954/0x12d0:\nkmalloc_noprof at include/linux/slab.h:901\n(inlined by) kzalloc_noprof at include/linux/slab.h:1037\n(inlined by) device_private_init at drivers/base/core.c:3510\n(inlined by) device_add at drivers/base/core.c:3561\n\nBalance device refcount by issuing a put_device() on devices found via\ndevice_find_child().(CVE-2025-37905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()\n\nA NULL pointer dereference can occur in skb_dequeue() when processing a\nQCA firmware crash dump on WCN7851 (0489:e0f3).\n\n[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)\n\n[ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]\n[ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80\n\nThe issue stems from handle_dump_pkt_qca() returning 0 even when a dump\npacket is successfully processed. This is because it incorrectly\nforwards the return value of hci_devcd_init() (which returns 0 on\nsuccess). As a result, the caller (btusb_recv_acl_qca() or\nbtusb_recv_evt_qca()) assumes the packet was not handled and passes it\nto hci_recv_frame(), leading to premature kfree() of the skb.\n\nLater, hci_devcd_rx() attempts to dequeue the same skb from the dump\nqueue, resulting in a NULL pointer dereference.\n\nFix this by:\n1. Making handle_dump_pkt_qca() return 0 on success and negative errno\n   on failure, consistent with kernel conventions.\n2. Splitting dump packet detection into separate functions for ACL\n   and event packets for better structure and readability.\n\nThis ensures dump packets are properly identified and consumed, avoiding\ndouble handling and preventing NULL pointer access.(CVE-2025-37918)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: prevent out-of-bounds stream writes by validating *pos\n\nksmbd_vfs_stream_write() did not validate whether the write offset\n(*pos) was within the bounds of the existing stream data length (v_len).\nIf *pos was greater than or equal to v_len, this could lead to an\nout-of-bounds memory write.\n\nThis patch adds a check to ensure *pos is less than v_len before\nproceeding. If the condition fails, -EINVAL is returned.(CVE-2025-37947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: displayport: Fix deadlock\n\nThis patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock\nfunctions to the UCSI driver. ucsi_con_mutex_lock ensures the connector\nmutex is only locked if a connection is established and the partner pointer\nis valid. This resolves a deadlock scenario where\nucsi_displayport_remove_partner holds con->mutex waiting for\ndp_altmode_work to complete while dp_altmode_work attempts to acquire it.(CVE-2025-37967)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Refactor remove call with idxd_cleanup() helper\n\nThe idxd_cleanup() helper cleans up perfmon, interrupts, internals and\nso on. Refactor remove call with the idxd_cleanup() helper to avoid code\nduplication. Note, this also fixes the missing put_device() for idxd\ngroups, enginces and wqs.(CVE-2025-38014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Annotate FDB data races\n\nThe 'used' and 'updated' fields in the FDB entry structure can be\naccessed concurrently by multiple threads, leading to reports such as\n[1]. Can be reproduced using [2].\n\nSuppress these reports by annotating these accesses using\nREAD_ONCE() / WRITE_ONCE().\n\n[1]\nBUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit\n\nwrite to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0:\n vxlan_xmit+0xb29/0x2380\n dev_hard_start_xmit+0x84/0x2f0\n __dev_queue_xmit+0x45a/0x1650\n packet_xmit+0x100/0x150\n packet_sendmsg+0x2114/0x2ac0\n __sys_sendto+0x318/0x330\n __x64_sys_sendto+0x76/0x90\n x64_sys_call+0x14e8/0x1c00\n do_syscall_64+0x9e/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2:\n vxlan_xmit+0xadf/0x2380\n dev_hard_start_xmit+0x84/0x2f0\n __dev_queue_xmit+0x45a/0x1650\n packet_xmit+0x100/0x150\n packet_sendmsg+0x2114/0x2ac0\n __sys_sendto+0x318/0x330\n __x64_sys_sendto+0x76/0x90\n x64_sys_call+0x14e8/0x1c00\n do_syscall_64+0x9e/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nvalue changed: 0x00000000fffbac6e -> 0x00000000fffbac6f\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014\n\n[2]\n #!/bin/bash\n\n set +H\n echo whitelist > /sys/kernel/debug/kcsan\n echo !vxlan_xmit > /sys/kernel/debug/kcsan\n\n ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1\n taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &\n taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &(CVE-2025-38037)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_ffa: Set dma_mask for ffa devices\n\nSet dma_mask for FFA devices, otherwise DMA allocation using the device pointer\nlead to following warning:\n\nWARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124(CVE-2025-38043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix use-after-free in cifs_fill_dirent\n\nThere is a race condition in the readdir concurrency process, which may\naccess the rsp buffer after it has been released, triggering the\nfollowing KASAN warning.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]\n Read of size 4 at addr ffff8880099b819c by task a.out/342975\n\n CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x53/0x70\n  print_report+0xce/0x640\n  kasan_report+0xb8/0xf0\n  cifs_fill_dirent+0xb03/0xb60 [cifs]\n  cifs_readdir+0x12cb/0x3190 [cifs]\n  iterate_dir+0x1a1/0x520\n  __x64_sys_getdents+0x134/0x220\n  do_syscall_64+0x4b/0x110\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f996f64b9f9\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89\n f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01\n f0 ff ff  0d f7 c3 0c 00 f7 d8 64 89 8\n RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e\n RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\n RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88\n R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000\n  </TASK>\n\n Allocated by task 408:\n  kasan_save_stack+0x20/0x40\n  kasan_save_track+0x14/0x30\n  __kasan_slab_alloc+0x6e/0x70\n  kmem_cache_alloc_noprof+0x117/0x3d0\n  mempool_alloc_noprof+0xf2/0x2c0\n  cifs_buf_get+0x36/0x80 [cifs]\n  allocate_buffers+0x1d2/0x330 [cifs]\n  cifs_demultiplex_thread+0x22b/0x2690 [cifs]\n  kthread+0x394/0x720\n  ret_from_fork+0x34/0x70\n  ret_from_fork_asm+0x1a/0x30\n\n Freed by task 342979:\n  kasan_save_stack+0x20/0x40\n  kasan_save_track+0x14/0x30\n  kasan_save_free_info+0x3b/0x60\n  __kasan_slab_free+0x37/0x50\n  kmem_cache_free+0x2b8/0x500\n  cifs_buf_release+0x3c/0x70 [cifs]\n  cifs_readdir+0x1c97/0x3190 [cifs]\n  iterate_dir+0x1a1/0x520\n  __x64_sys_getdents64+0x134/0x220\n  do_syscall_64+0x4b/0x110\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n The buggy address belongs to the object at ffff8880099b8000\n  which belongs to the cache cifs_request of size 16588\n The buggy address is located 412 bytes inside of\n  freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8\n head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n anon flags: 0x80000000000040(head|node=0|zone=1)\n page_type: f5(slab)\n raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff\n head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n  ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                             ^\n  ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ==================================================================\n\nPOC is available in the link [1].\n\nThe problem triggering process is as follows:\n\nProcess 1                       Process 2\n-----------------------------------\n---truncated---(CVE-2025-38051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio: break and reset virtio devices on device_shutdown()\n\nHongyu reported a hang on kexec in a VM. QEMU reported invalid memory\naccesses during the hang.\n\n\tInvalid read at addr 0x102877002, size 2, region '(null)', reason: rejected\n\tInvalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected\n\t...\n\nIt was traced down to virtio-console. Kexec works fine if virtio-console\nis not in use.\n\nThe issue is that virtio-console continues to write to the MMIO even after\nunderlying virtio-pci device is reset.\n\nAdditionally, Eric noticed that IOMMUs are reset before devices, if\ndevices are not reset on shutdown they continue to poke at guest memory\nand get errors from the IOMMU. Some devices get wedged then.\n\nThe problem can be solved by breaking all virtio devices on virtio\nbus shutdown, then resetting them.(CVE-2025-38064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: CPPC: Fix NULL pointer dereference when nosmp is used\n\nWith nosmp in cmdline, other CPUs are not brought up, leaving\ntheir cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu()\ndereferences these NULL pointers, causing panic.\n\nPanic backtrace:\n\n[    0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8\n...\n[    0.403255] [<ffffffff809a5818>] cppc_allow_fast_switch+0x6a/0xd4\n...\nKernel panic - not syncing: Attempted to kill init!\n\n[ rjw: New subject ](CVE-2025-38113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngve: add missing NULL check for gve_alloc_pending_packet() in TX DQO\n\ngve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()\ndid not check for this case before dereferencing the returned pointer.\n\nAdd a missing NULL check to prevent a potential NULL pointer\ndereference when allocation fails.\n\nThis improves robustness in low-memory scenarios.(CVE-2025-38122)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: t7xx: Fix napi rx poll issue\n\nWhen driver handles the napi rx polling requests, the netdev might\nhave been released by the dellink logic triggered by the disconnect\noperation on user plane. However, in the logic of processing skb in\npolling, an invalid netdev is still being used, which causes a panic.\n\nBUG: kernel NULL pointer dereference, address: 00000000000000f1\nOops: 0000 [#1] PREEMPT SMP NOPTI\nRIP: 0010:dev_gro_receive+0x3a/0x620\n[...]\nCall Trace:\n <IRQ>\n ? __die_body+0x68/0xb0\n ? page_fault_oops+0x379/0x3e0\n ? exc_page_fault+0x4f/0xa0\n ? asm_exc_page_fault+0x22/0x30\n ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)]\n ? dev_gro_receive+0x3a/0x620\n napi_gro_receive+0xad/0x170\n t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)]\n t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)]\n net_rx_action+0x103/0x470\n irq_exit_rcu+0x13a/0x310\n sysvec_apic_timer_interrupt+0x56/0x90\n </IRQ>(CVE-2025-38123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: prevent deactivate active config while enabling the config\n\nWhile enable active config via cscfg_csdev_enable_active_config(),\nactive config could be deactivated via configfs' sysfs interface.\nThis could make UAF issue in below scenario:\n\nCPU0                                          CPU1\n(sysfs enable)                                load module\n                                              cscfg_load_config_sets()\n                                              activate config. // sysfs\n                                              (sys_active_cnt == 1)\n...\ncscfg_csdev_enable_active_config()\nlock(csdev->cscfg_csdev_lock)\n// here load config activate by CPU1\nunlock(csdev->cscfg_csdev_lock)\n\n                                              deactivate config // sysfs\n                                              (sys_activec_cnt == 0)\n                                              cscfg_unload_config_sets()\n                                              unload module\n\n// access to config_desc which freed\n// while unloading module.\ncscfg_csdev_enable_config\n\nTo address this, use cscfg_config_desc's active_cnt as a reference count\n which will be holded when\n    - activate the config.\n    - enable the activated config.\nand put the module reference when config_active_cnt == 0.(CVE-2025-38131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: mscc: Fix memory leak when using one step timestamping\n\nFix memory leak when running one-step timestamping. When running\none-step sync timestamping, the HW is configured to insert the TX time\ninto the frame, so there is no reason to keep the skb anymore. As in\nthis case the HW will never generate an interrupt to say that the frame\nwas timestamped, then the frame will never released.\nFix this by freeing the frame in case of one-step timestamping.(CVE-2025-38148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix error flow upon firmware failure for RQ destruction\n\nUpon RQ destruction if the firmware command fails which is the\nlast resource to be destroyed some SW resources were already cleaned\nregardless of the failure.\n\nNow properly rollback the object to its original state upon such failure.\n\nIn order to avoid a use-after free in case someone tries to destroy the\nobject again, which results in the following kernel trace:\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148\nModules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)\nCPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G           OE     -------  ---  6.12.0-54.el10.aarch64 #1\nTainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\nHardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : refcount_warn_saturate+0xf4/0x148\nlr : refcount_warn_saturate+0xf4/0x148\nsp : ffff80008b81b7e0\nx29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001\nx26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00\nx23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000\nx20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006\nx17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f\nx14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78\nx11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90\nx8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff\nx5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600\nCall trace:\n refcount_warn_saturate+0xf4/0x148\n mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib]\n mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib]\n mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib]\n ib_destroy_wq_user+0x30/0xc0 [ib_core]\n uverbs_free_wq+0x28/0x58 [ib_uverbs]\n destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs]\n uverbs_destroy_uobject+0x48/0x240 [ib_uverbs]\n __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs]\n uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs]\n ib_uverbs_close+0x2c/0x100 [ib_uverbs]\n __fput+0xd8/0x2f0\n __fput_sync+0x50/0x70\n __arm64_sys_close+0x40/0x90\n invoke_syscall.constprop.0+0x74/0xd0\n do_el0_svc+0x48/0xe8\n el0_svc+0x44/0x1d0\n el0t_64_sync_handler+0x120/0x130\n el0t_64_sync+0x1a4/0x1a8(CVE-2025-38161)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get()\n\nBefore calling lan743x_ptp_io_event_clock_get(), the 'channel' value\nis checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8).\nThis seems correct and aligns with the PTP interrupt status register\n(PTP_INT_STS) specifications.\n\nHowever, lan743x_ptp_io_event_clock_get() writes to ptp->extts[] with\nonly LAN743X_PTP_N_EXTTS(4) elements, using channel as an index:\n\n    lan743x_ptp_io_event_clock_get(..., u8 channel,...)\n    {\n        ...\n        /* Update Local timestamp */\n        extts = &ptp->extts[channel];\n        extts->ts.tv_sec = sec;\n        ...\n    }\n\nTo avoid an out-of-bounds write and utilize all the supported GPIO\ninputs, set LAN743X_PTP_N_EXTTS to 8.\n\nDetected using the static analysis tool - Svace.(CVE-2025-38183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: reject invalid perturb period\n\nGerrard Tai reported that SFQ perturb_period has no range check yet,\nand this can be used to trigger a race condition fixed in a separate patch.\n\nWe want to make sure ctl->perturb_period * HZ will not overflow\nand is positive.\n\n\ntc qd add dev lo root sfq perturb -10   # negative value : error\nError: sch_sfq: invalid perturb period.\n\ntc qd add dev lo root sfq perturb 1000000000 # too big : error\nError: sch_sfq: invalid perturb period.\n\ntc qd add dev lo root sfq perturb 2000000 # acceptable value\ntc -s -d qd sh dev lo\nqdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec\n Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)\n backlog 0b 0p requeues 0(CVE-2025-38193)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: check that raw node were preallocated before writing summary\n\nSyzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault\ninjection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't\ncheck return value of jffs2_prealloc_raw_node_refs and simply lets any\nerror propagate into jffs2_sum_write_data, which eventually calls\njffs2_link_node_ref in order to link the summary to an expectedly allocated\nnode.\n\nkernel BUG at fs/jffs2/nodelist.c:592!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592\nCall Trace:\n <TASK>\n jffs2_sum_write_data fs/jffs2/summary.c:841 [inline]\n jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874\n jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388\n jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197\n jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362\n jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301\n generic_perform_write+0x314/0x5d0 mm/filemap.c:3856\n __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973\n generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005\n call_write_iter include/linux/fs.h:2265 [inline]\n do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735\n do_iter_write+0x186/0x710 fs/read_write.c:861\n vfs_iter_write+0x70/0xa0 fs/read_write.c:902\n iter_file_splice_write+0x73b/0xc90 fs/splice.c:685\n do_splice_from fs/splice.c:763 [inline]\n direct_splice_actor+0x10c/0x170 fs/splice.c:950\n splice_direct_to_actor+0x337/0xa10 fs/splice.c:896\n do_splice_direct+0x1a9/0x280 fs/splice.c:1002\n do_sendfile+0xb13/0x12c0 fs/read_write.c:1255\n __do_sys_sendfile64 fs/read_write.c:1323 [inline]\n __se_sys_sendfile64 fs/read_write.c:1309 [inline]\n __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nFix this issue by checking return value of jffs2_prealloc_raw_node_refs\nbefore calling jffs2_sum_write_data.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-38194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/shmem, swap: fix softlockup with mTHP swapin\n\nFollowing softlockup can be easily reproduced on my test machine with:\n\necho always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled\nswapon /dev/zram0 # zram0 is a 48G swap device\nmkdir -p /sys/fs/cgroup/memory/test\necho 1G > /sys/fs/cgroup/test/memory.max\necho $BASHPID > /sys/fs/cgroup/test/cgroup.procs\nwhile true; do\n    dd if=/dev/zero of=/tmp/test.img bs=1M count=5120\n    cat /tmp/test.img > /dev/null\n    rm /tmp/test.img\ndone\n\nThen after a while:\nwatchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]\nModules linked in: zram virtiofs\nCPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G             L      6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)·\nTainted: [L]=SOFTLOCKUP\nHardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015\nRIP: 0010:mpol_shared_policy_lookup+0xd/0x70\nCode: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8\nRSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202\nRAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001\nRDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518\nRBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001\nR13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000\nFS:  00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <TASK>\n shmem_alloc_folio+0x31/0xc0\n shmem_swapin_folio+0x309/0xcf0\n ? filemap_get_entry+0x117/0x1e0\n ? xas_load+0xd/0xb0\n ? filemap_get_entry+0x101/0x1e0\n shmem_get_folio_gfp+0x2ed/0x5b0\n shmem_file_read_iter+0x7f/0x2e0\n vfs_read+0x252/0x330\n ksys_read+0x68/0xf0\n do_syscall_64+0x4c/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f03f9a46991\nCode: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\nRSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991\nRDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003\nRBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\nR13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000\n </TASK>\n\nThe reason is simple, readahead brought some order 0 folio in swap cache,\nand the swapin mTHP folio being allocated is in conflict with it, so\nswapcache_prepare fails and causes shmem_swap_alloc_folio to return\n-EEXIST, and shmem simply retries again and again causing this loop.\n\nFix it by applying a similar fix for anon mTHP swapin.\n\nThe performance change is very slight, time of swapin 10g zero folios\nwith shmem (test for 12 times):\nBefore:  2.47s\nAfter:   2.48s\n\n[(CVE-2025-38241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()\n\nWhile testing null_blk with configfs, echo 0 > poll_queues will trigger\nfollowing panic:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000010\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014\nRIP: 0010:__bitmap_or+0x48/0x70\nCall Trace:\n <TASK>\n __group_cpus_evenly+0x822/0x8c0\n group_cpus_evenly+0x2d9/0x490\n blk_mq_map_queues+0x1e/0x110\n null_map_queues+0xc9/0x170 [null_blk]\n blk_mq_update_queue_map+0xdb/0x160\n blk_mq_update_nr_hw_queues+0x22b/0x560\n nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]\n nullb_device_poll_queues_store+0xa4/0x130 [null_blk]\n configfs_write_iter+0x109/0x1d0\n vfs_write+0x26e/0x6f0\n ksys_write+0x79/0x180\n __x64_sys_write+0x1d/0x30\n x64_sys_call+0x45c4/0x45f0\n do_syscall_64+0xa5/0x240\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nRoot cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from\nkcalloc(), and later ZERO_SIZE_PTR will be deferenced.\n\nFix the problem by checking numgrps first in group_cpus_evenly(), and\nreturn NULL directly if numgrps is zero.\n\n[(CVE-2025-38255)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix NULL pointer deference on eir_get_service_data\n\nThe len parameter is considered optional so it can be NULL so it cannot\nbe used for skipping to next entry of EIR_SERVICE_DATA.(CVE-2025-38304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: avs: Verify content returned by parse_int_array()\n\nThe first element of the returned array stores its length. If it is 0,\nany manipulation beyond the element at index 0 ends with null-ptr-deref.(CVE-2025-38307)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: Log an error when close_all_cached_dirs fails\n\nUnder low-memory conditions, close_all_cached_dirs() can't move the\ndentries to a separate list to dput() them once the locks are dropped.\nThis will result in a "Dentry still in use" error, so add an error\nmessage that makes it clear this is what happened:\n\n[  495.281119] CIFS: VFS: \\\\otters.example.com\\share Out of memory while dropping dentries\n[  495.281595] ------------[ cut here ]------------\n[  495.281887] BUG: Dentry ffff888115531138{i=78,n=/}  still in use (2) [unmount of cifs cifs]\n[  495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0\n\nAlso, bail out of looping through all tcons as soon as a single\nallocation fails, since we're already in trouble, and kmalloc() attempts\nfor subseqeuent tcons are likely to fail just like the first one did.(CVE-2025-38321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: fix acpi parse and parseext cache leaks\n\nACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5\n\nI'm Seunghun Han, and I work for National Security Research Institute of\nSouth Korea.\n\nI have been doing a research on ACPI and found an ACPI cache leak in ACPI\nearly abort cases.\n\nBoot log of ACPI cache leak is as follows:\n[    0.352414] ACPI: Added _OSI(Module Device)\n[    0.353182] ACPI: Added _OSI(Processor Device)\n[    0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)\n[    0.353182] ACPI: Added _OSI(Processor Aggregator Device)\n[    0.356028] ACPI: Unable to start the ACPI Interpreter\n[    0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)\n[    0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects\n[    0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W\n4.12.0-rc4-next-20170608+ #10\n[    0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS\nvirtual_box 12/01/2006\n[    0.361873] Call Trace:\n[    0.362243]  ? dump_stack+0x5c/0x81\n[    0.362591]  ? kmem_cache_destroy+0x1aa/0x1c0\n[    0.362944]  ? acpi_sleep_proc_init+0x27/0x27\n[    0.363296]  ? acpi_os_delete_cache+0xa/0x10\n[    0.363646]  ? acpi_ut_delete_caches+0x6d/0x7b\n[    0.364000]  ? acpi_terminate+0xa/0x14\n[    0.364000]  ? acpi_init+0x2af/0x34f\n[    0.364000]  ? __class_create+0x4c/0x80\n[    0.364000]  ? video_setup+0x7f/0x7f\n[    0.364000]  ? acpi_sleep_proc_init+0x27/0x27\n[    0.364000]  ? do_one_initcall+0x4e/0x1a0\n[    0.364000]  ? kernel_init_freeable+0x189/0x20a\n[    0.364000]  ? rest_init+0xc0/0xc0\n[    0.364000]  ? kernel_init+0xa/0x100\n[    0.364000]  ? ret_from_fork+0x25/0x30\n\nI analyzed this memory leak in detail. I found that “Acpi-State” cache and\n“Acpi-Parse” cache were merged because the size of cache objects was same\nslab cache size.\n\nI finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked\nusing SLAB_NEVER_MERGE flag in kmem_cache_create() function.\n\nReal ACPI cache leak point is as follows:\n[    0.360101] ACPI: Added _OSI(Module Device)\n[    0.360101] ACPI: Added _OSI(Processor Device)\n[    0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)\n[    0.361043] ACPI: Added _OSI(Processor Aggregator Device)\n[    0.364016] ACPI: Unable to start the ACPI Interpreter\n[    0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)\n[    0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects\n[    0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W\n4.12.0-rc4-next-20170608+ #8\n[    0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS\nvirtual_box 12/01/2006\n[    0.372000] Call Trace:\n[    0.372000]  ? dump_stack+0x5c/0x81\n[    0.372000]  ? kmem_cache_destroy+0x1aa/0x1c0\n[    0.372000]  ? acpi_sleep_proc_init+0x27/0x27\n[    0.372000]  ? acpi_os_delete_cache+0xa/0x10\n[    0.372000]  ? acpi_ut_delete_caches+0x56/0x7b\n[    0.372000]  ? acpi_terminate+0xa/0x14\n[    0.372000]  ? acpi_init+0x2af/0x34f\n[    0.372000]  ? __class_create+0x4c/0x80\n[    0.372000]  ? video_setup+0x7f/0x7f\n[    0.372000]  ? acpi_sleep_proc_init+0x27/0x27\n[    0.372000]  ? do_one_initcall+0x4e/0x1a0\n[    0.372000]  ? kernel_init_freeable+0x189/0x20a\n[    0.372000]  ? rest_init+0xc0/0xc0\n[    0.372000]  ? kernel_init+0xa/0x100\n[    0.372000]  ? ret_from_fork+0x25/0x30\n[    0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects\n[    0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W\n4.12.0-rc4-next-20170608+ #8\n[    0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS\nvirtual_box 12/01/2006\n[    0.392000] Call Trace:\n[    0.392000]  ? dump_stack+0x5c/0x81\n[    0.392000]  ? kmem_cache_destroy+0x1aa/0x1c0\n[    0.392000]  ? acpi_sleep_proc_init+0x27/0x27\n[    0.392000]  ? acpi_os_delete_cache+0xa/0x10\n[    0.392000]  ? acpi_ut_delete_caches+0x6d/0x7b\n[    0.392000]  ? acpi_terminate+0xa/0x14\n[    0.392000]  ? acpi_init+0x2af/0x3\n---truncated---(CVE-2025-38344)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmaple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()\n\nTemporarily clear the preallocation flag when explicitly requesting\nallocations.  Pre-existing allocations are already counted against the\nrequest through mas_node_count_gfp(), but the allocations will not happen\nif the MA_STATE_PREALLOC flag is set.  This flag is meant to avoid\nre-allocating in bulk allocation mode, and to detect issues with\npreallocation calculations.\n\nThe MA_STATE_PREALLOC flag should also always be set on zero allocations\nso that detection of underflow allocations will print a WARN_ON() during\nconsumption.\n\nUser visible effect of this flaw is a WARN_ON() followed by a null pointer\ndereference when subsequent requests for larger number of nodes is\nignored, such as the vma merge retry in mmap_region() caused by drivers\naltering the vma flags (which happens in v6.6, at least)(CVE-2025-38364)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Fix transport_* TOCTOU\n\nTransport assignment may race with module unload. Protect new_transport\nfrom becoming a stale pointer.\n\nThis also takes care of an insecure call in vsock_use_local_transport();\nadd a lockdep assert.\n\nBUG: unable to handle page fault for address: fffffbfff8056000\nOops: Oops: 0000 [#1] SMP KASAN\nRIP: 0010:vsock_assign_transport+0x366/0x600\nCall Trace:\n vsock_connect+0x59c/0xc40\n __sys_connect+0xe8/0x100\n __x64_sys_connect+0x6e/0xc0\n do_syscall_64+0x92/0x1c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38461)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Fix transport_{g2h,h2g} TOCTOU\n\nvsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.\ntransport_{g2h,h2g} may become NULL after the NULL check.\n\nIntroduce vsock_transport_local_cid() to protect from a potential\nnull-ptr-deref.\n\nKASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\nRIP: 0010:vsock_find_cid+0x47/0x90\nCall Trace:\n __vsock_bind+0x4b2/0x720\n vsock_bind+0x90/0xe0\n __sys_bind+0x14d/0x1e0\n __x64_sys_bind+0x6e/0xc0\n do_syscall_64+0x92/0x1c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nKASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\nRIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0\nCall Trace:\n __x64_sys_ioctl+0x12d/0x190\n do_syscall_64+0x92/0x1c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38462)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in crypt_message when using async crypto\n\nThe CVE-2024-50047 fix removed asynchronous crypto handling from\ncrypt_message(), assuming all crypto operations are synchronous.\nHowever, when hardware crypto accelerators are used, this can cause\nuse-after-free crashes:\n\n  crypt_message()\n    // Allocate the creq buffer containing the req\n    creq = smb2_get_aead_req(..., &req);\n\n    // Async encryption returns -EINPROGRESS immediately\n    rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);\n\n    // Free creq while async operation is still in progress\n    kvfree_sensitive(creq, ...);\n\nHardware crypto modules often implement async AEAD operations for\nperformance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,\nthe operation completes asynchronously. Without crypto_wait_req(),\nthe function immediately frees the request buffer, leading to crashes\nwhen the driver later accesses the freed memory.\n\nThis results in a use-after-free condition when the hardware crypto\ndriver later accesses the freed request structure, leading to kernel\ncrashes with NULL pointer dereferences.\n\nThe issue occurs because crypto_alloc_aead() with mask=0 doesn't\nguarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in\nthe mask, async implementations can be selected.\n\nFix by restoring the async crypto handling:\n- DECLARE_CRYPTO_WAIT(wait) for completion tracking\n- aead_request_set_callback() for async completion notification\n- crypto_wait_req() to wait for operation completion\n\nThis ensures the request buffer isn't freed until the crypto operation\ncompletes, whether synchronous or asynchronous, while preserving the\nCVE-2024-50047 fix.(CVE-2025-38488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns\n\nWhat we want is to verify there is that clone won't expose something\nhidden by a mount we wouldn't be able to undo.  "Wouldn't be able to undo"\nmay be a result of MNT_LOCKED on a child, but it may also come from\nlacking admin rights in the userns of the namespace mount belongs to.\n\nclone_private_mnt() checks the former, but not the latter.\n\nThere's a number of rather confusing CAP_SYS_ADMIN checks in various\nuserns during the mount, especially with the new mount API; they serve\ndifferent purposes and in case of clone_private_mnt() they usually,\nbut not always end up covering the missing check mentioned above.(CVE-2025-38499)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: plug races between subflow fail and subflow creation\n\nWe have races similar to the one addressed by the previous patch between\nsubflow failing and additional subflow creation. They are just harder to\ntrigger.\n\nThe solution is similar. Use a separate flag to track the condition\n'socket state prevent any additional subflow creation' protected by the\nfallback lock.\n\nThe socket fallback makes such flag true, and also receiving or sending\nan MP_FAIL option.\n\nThe field 'allow_infinite_fallback' is now always touched under the\nrelevant lock, we can drop the ONCE annotation on write.(CVE-2025-38552)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: use aead_request_free to match aead_request_alloc\n\nUse aead_request_free() instead of kfree() to properly free memory\nallocated by aead_request_alloc(). This ensures sensitive crypto data\nis zeroed before being freed.(CVE-2025-38575)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Check governor before using governor->name\n\nCommit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name from\nstruct devfreq") removes governor_name and uses governor->name to replace\nit. But devfreq->governor may be NULL and directly using\ndevfreq->governor->name may cause null pointer exception. Move the check of\ngovernor to before using governor->name.(CVE-2025-38609)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: fix refcount leak on table dump\n\nThere is a reference count leak in ctnetlink_dump_table():\n      if (res < 0) {\n                nf_conntrack_get(&ct->ct_general); // HERE\n                cb->args[1] = (unsigned long)ct;\n                ...\n\nWhile its very unlikely, its possible that ct == last.\nIf this happens, then the refcount of ct was already incremented.\nThis 2nd increment is never undone.\n\nThis prevents the conntrack object from being released, which in turn\nkeeps prevents cnet->count from dropping back to 0.\n\nThis will then block the netns dismantle (or conntrack rmmod) as\nnf_conntrack_cleanup_net_list() will wait forever.\n\nThis can be reproduced by running conntrack_resize.sh selftest in a loop.\nIt takes ~20 minutes for me on a preemptible kernel on average before\nI see a runaway kworker spinning in nf_conntrack_cleanup_net_list.\n\nOne fix would to change this to:\n        if (res < 0) {\n\t\tif (ct != last)\n\t                nf_conntrack_get(&ct->ct_general);\n\nBut this reference counting isn't needed in the first place.\nWe can just store a cookie value instead.\n\nA followup patch will do the same for ctnetlink_exp_dump_table,\nit looks to me as if this has the same problem and like\nctnetlink_dump_table, we only need a 'skip hint', not the actual\nobject so we can apply the same cookie strategy there as well.(CVE-2025-38721)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla4xxx: Prevent a potential error pointer dereference\n\nThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,\nbut qla4xxx_ep_connect() returns error pointers.  Propagating the error\npointers will lead to an Oops in the caller, so change the error pointers\nto NULL.(CVE-2025-39676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: fix handling of zero-length records on the rx_list\n\nEach recvmsg() call must process either\n - only contiguous DATA records (any number of them)\n - one non-DATA record\n\nIf the next record has different type than what has already been\nprocessed we break out of the main processing loop. If the record\nhas already been decrypted (which may be the case for TLS 1.3 where\nwe don't know type until decryption) we queue the pending record\nto the rx_list. Next recvmsg() will pick it up from there.\n\nQueuing the skb to rx_list after zero-copy decrypt is not possible,\nsince in that case we decrypted directly to the user space buffer,\nand we don't have an skb to queue (darg.skb points to the ciphertext\nskb for access to metadata like length).\n\nOnly data records are allowed zero-copy, and we break the processing\nloop after each non-data record. So we should never zero-copy and\nthen find out that the record type has changed. The corner case\nwe missed is when the initial record comes from rx_list, and it's\nzero length.(CVE-2025-39682)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sr: Fix MAC comparison to be constant-time\n\nTo prevent timing attacks, MACs need to be compared in constant time.\nUse the appropriate helper function for this.(CVE-2025-39702)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: samsung: Fix UBSAN panic in samsung_clk_init()\n\nWith UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to\ndereferencing `ctx->clk_data.hws` before setting\n`ctx->clk_data.num = nr_clks`. Move that up to fix the crash.\n\n  UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP\n  <snip>\n  Call trace:\n   samsung_clk_init+0x110/0x124 (P)\n   samsung_clk_init+0x48/0x124 (L)\n   samsung_cmu_register_one+0x3c/0xa0\n   exynos_arm64_register_cmu+0x54/0x64\n   __gs101_cmu_top_of_clk_init_declare+0x28/0x60\n   ...(CVE-2025-39728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: Prevent file descriptor table allocations exceeding INT_MAX\n\nWhen sysctl_nr_open is set to a very high value (for example, 1073741816\nas set by systemd), processes attempting to use file descriptors near\nthe limit can trigger massive memory allocation attempts that exceed\nINT_MAX, resulting in a WARNING in mm/slub.c:\n\n  WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288\n\nThis happens because kvmalloc_array() and kvmalloc() check if the\nrequested size exceeds INT_MAX and emit a warning when the allocation is\nnot flagged with __GFP_NOWARN.\n\nSpecifically, when nr_open is set to 1073741816 (0x3ffffff8) and a\nprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:\n- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes\n- Multiple bitmaps: ~400MB\n- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)\n\nReproducer:\n1. Set /proc/sys/fs/nr_open to 1073741816:\n   # echo 1073741816 > /proc/sys/fs/nr_open\n\n2. Run a program that uses a high file descriptor:\n   #include <unistd.h>\n   #include <sys/resource.h>\n\n   int main() {\n       struct rlimit rlim = {1073741824, 1073741824};\n       setrlimit(RLIMIT_NOFILE, &rlim);\n       dup2(2, 1073741880);  // Triggers the warning\n       return 0;\n   }\n\n3. Observe WARNING in dmesg at mm/slub.c:5027\n\nsystemd commit a8b627a introduced automatic bumping of fs.nr_open to the\nmaximum possible value. The rationale was that systems with memory\ncontrol groups (memcg) no longer need separate file descriptor limits\nsince memory is properly accounted. However, this change overlooked\nthat:\n\n1. The kernel's allocation functions still enforce INT_MAX as a maximum\n   size regardless of memcg accounting\n2. Programs and tests that legitimately test file descriptor limits can\n   inadvertently trigger massive allocations\n3. The resulting allocations (>8GB) are impractical and will always fail\n\nsystemd's algorithm starts with INT_MAX and keeps halving the value\nuntil the kernel accepts it. On most systems, this results in nr_open\nbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of file\ndescriptors.\n\nWhile processes rarely use file descriptors near this limit in normal\noperation, certain selftests (like\ntools/testing/selftests/core/unshare_test.c) and programs that test file\ndescriptor limits can trigger this issue.\n\nFix this by adding a check in alloc_fdtable() to ensure the requested\nallocation size does not exceed INT_MAX. This causes the operation to\nfail with -EMFILE instead of triggering a kernel warning and avoids the\nimpractical >8GB memory allocation request.(CVE-2025-39756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM\n\nWhen performing Generic Segmentation Offload (GSO) on an IPv6 packet that\ncontains extension headers, the kernel incorrectly requests checksum offload\nif the egress device only advertises NETIF_F_IPV6_CSUM feature, which has\na strict contract: it supports checksum offload only for plain TCP or UDP\nover IPv6 and explicitly does not support packets with extension headers.\nThe current GSO logic violates this contract by failing to disable the feature\nfor packets with extension headers, such as those used in GREoIPv6 tunnels.\n\nThis violation results in the device being asked to perform an operation\nit cannot support, leading to a `skb_warn_bad_offload` warning and a collapse\nof network throughput. While device TSO/USO is correctly bypassed in favor\nof software GSO for these packets, the GSO stack must be explicitly told not\nto request checksum offload.\n\nMask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4\nin gso_features_check if the IPv6 header contains extension headers to compute\nchecksum in software.\n\nThe exception is a BIG TCP extension, which, as stated in commit\n68e068cabd2c6c53 ("net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets"):\n"The feature is only enabled on devices that support BIG TCP TSO.\nThe header is only present for PF_PACKET taps like tcpdump,\nand not transmitted by physical devices."\n\nkernel log output (truncated):\nWARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140\n...\nCall Trace:\n <TASK>\n skb_checksum_help+0x12a/0x1f0\n validate_xmit_skb+0x1a3/0x2d0\n validate_xmit_skb_list+0x4f/0x80\n sch_direct_xmit+0x1a2/0x380\n __dev_xmit_skb+0x242/0x670\n __dev_queue_xmit+0x3fc/0x7f0\n ip6_finish_output2+0x25e/0x5d0\n ip6_finish_output+0x1fc/0x3f0\n ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel]\n ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre]\n dev_hard_start_xmit+0x63/0x1c0\n __dev_queue_xmit+0x6d0/0x7f0\n ip6_finish_output2+0x214/0x5d0\n ip6_finish_output+0x1fc/0x3f0\n ip6_xmit+0x2ca/0x6f0\n ip6_finish_output+0x1fc/0x3f0\n ip6_xmit+0x2ca/0x6f0\n inet6_csk_xmit+0xeb/0x150\n __tcp_transmit_skb+0x555/0xa80\n tcp_write_xmit+0x32a/0xe90\n tcp_sendmsg_locked+0x437/0x1110\n tcp_sendmsg+0x2f/0x50\n...\nskb linear:   00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e\nskb linear:   00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00\nskb linear:   00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00\nskb linear:   00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00\nskb linear:   00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00\nskb linear:   00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00\nskb linear:   00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9\nskb linear:   00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01\nskb linear:   00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a(CVE-2025-39770)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: initialize more fields in sctp_v6_from_sk()\n\nsyzbot found that sin6_scope_id was not properly initialized,\nleading to undefined behavior.\n\nClear sin6_scope_id and sin6_flowinfo.\n\nBUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649\n  __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649\n  sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983\n  sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390\n  sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452\n  sctp_get_port net/sctp/socket.c:8523 [inline]\n  sctp_listen_start net/sctp/socket.c:8567 [inline]\n  sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636\n  __sys_listen_socket net/socket.c:1912 [inline]\n  __sys_listen net/socket.c:1927 [inline]\n  __do_sys_listen net/socket.c:1932 [inline]\n  __se_sys_listen net/socket.c:1930 [inline]\n  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930\n  x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nLocal variable addr.i.i created at:\n  sctp_get_port net/sctp/socket.c:8515 [inline]\n  sctp_listen_start net/sctp/socket.c:8567 [inline]\n  sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636\n  __sys_listen_socket net/socket.c:1912 [inline]\n  __sys_listen net/socket.c:1927 [inline]\n  __do_sys_listen net/socket.c:1932 [inline]\n  __se_sys_listen net/socket.c:1930 [inline]\n  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930(CVE-2025-39812)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix buffer free/clear order in deferred receive path\n\nFix a use-after-free window by correcting the buffer release sequence in\nthe deferred receive path. The code freed the RQ buffer first and only\nthen cleared the context pointer under the lock. Concurrent paths (e.g.,\nABTS and the repost path) also inspect and release the same pointer under\nthe lock, so the old order could lead to double-free/UAF.\n\nNote that the repost path already uses the correct pattern: detach the\npointer under the lock, then free it after dropping the lock. The\ndeferred path should do the same.(CVE-2025-39841)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm\n\nWhen send a broadcast packet to a tap device, which was added to a bridge,\nbr_nf_local_in() is called to confirm the conntrack. If another conntrack\nwith the same hash value is added to the hash table, which can be\ntriggered by a normal packet to a non-bridge device, the below warning\nmay happen.\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200\n  CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary)\n  RIP: 0010:br_nf_local_in+0x168/0x200\n  Call Trace:\n   <TASK>\n   nf_hook_slow+0x3e/0xf0\n   br_pass_frame_up+0x103/0x180\n   br_handle_frame_finish+0x2de/0x5b0\n   br_nf_hook_thresh+0xc0/0x120\n   br_nf_pre_routing_finish+0x168/0x3a0\n   br_nf_pre_routing+0x237/0x5e0\n   br_handle_frame+0x1ec/0x3c0\n   __netif_receive_skb_core+0x225/0x1210\n   __netif_receive_skb_one_core+0x37/0xa0\n   netif_receive_skb+0x36/0x160\n   tun_get_user+0xa54/0x10c0\n   tun_chr_write_iter+0x65/0xb0\n   vfs_write+0x305/0x410\n   ksys_write+0x60/0xd0\n   do_syscall_64+0xa4/0x260\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n   </TASK>\n  ---[ end trace 0000000000000000 ]---\n\nTo solve the hash conflict, nf_ct_resolve_clash() try to merge the\nconntracks, and update skb->_nfct. However, br_nf_local_in() still use the\nold ct from local variable 'nfct' after confirm(), which leads to this\nwarning.\n\nIf confirm() does not insert the conntrack entry and return NF_DROP, the\nwarning may also occur. There is no need to reserve the WARN_ON_ONCE, just\nremove it.(CVE-2025-39894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer\n\nSince commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from\ndevice property") rfkill_find_type() gets called with the possibly\nuninitialized "const char *type_name;" local variable.\n\nOn x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"\nacpi_device, the rfkill->type is set based on the ACPI acpi_device_id:\n\n        rfkill->type = (unsigned)id->driver_data;\n\nand there is no "type" property so device_property_read_string() will fail\nand leave type_name uninitialized, leading to a potential crash.\n\nrfkill_find_type() does accept a NULL pointer, fix the potential crash\nby initializing type_name to NULL.\n\nNote likely sofar this has not been caught because:\n\n1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device\n2. The stack happened to contain NULL where type_name is stored(CVE-2025-39937)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().\n\nsyzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk\nin the TCP_ESTABLISHED state. [0]\n\nsyzbot reused the server-side TCP Fast Open socket as a new client before\nthe TFO socket completes 3WHS:\n\n  1. accept()\n  2. connect(AF_UNSPEC)\n  3. connect() to another destination\n\nAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes\nit to TCP_CLOSE and makes connect() possible, which restarts timers.\n\nSince tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the\nretransmit timer triggered the warning and the intended packet was not\nretransmitted.\n\nLet's call reqsk_fastopen_remove() in tcp_disconnect().\n\n[0]:\nWARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))\nModules linked in:\nCPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))\nCode: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e\nRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293\nRAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017\nRDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400\nRBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8\nR10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540\nR13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0\nFS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0\nCall Trace:\n <IRQ>\n tcp_write_timer (net/ipv4/tcp_timer.c:738)\n call_timer_fn (kernel/time/timer.c:1747)\n __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)\n timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)\n tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)\n __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))\n tmigr_handle_remote (kernel/time/timer_migration.c:1096)\n handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)\n irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))\n </IRQ>(CVE-2025-39955)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnexthop: Forbid FDB status change while nexthop is in a group\n\nThe kernel forbids the creation of non-FDB nexthop groups with FDB\nnexthops:\n\n # ip nexthop add id 1 via 192.0.2.1 fdb\n # ip nexthop add id 2 group 1\n Error: Non FDB nexthop group cannot have fdb nexthops.\n\nAnd vice versa:\n\n # ip nexthop add id 3 via 192.0.2.2 dev dummy1\n # ip nexthop add id 4 group 3 fdb\n Error: FDB nexthop group can only have fdb nexthops.\n\nHowever, as long as no routes are pointing to a non-FDB nexthop group,\nthe kernel allows changing the type of a nexthop from FDB to non-FDB and\nvice versa:\n\n # ip nexthop add id 5 via 192.0.2.2 dev dummy1\n # ip nexthop add id 6 group 5\n # ip nexthop replace id 5 via 192.0.2.2 fdb\n # echo $?\n 0\n\nThis configuration is invalid and can result in a NPD [1] since FDB\nnexthops are not associated with a nexthop device:\n\n # ip route add 198.51.100.1/32 nhid 6\n # ping 198.51.100.1\n\nFix by preventing nexthop FDB status change while the nexthop is in a\ngroup:\n\n # ip nexthop add id 7 via 192.0.2.2 dev dummy1\n # ip nexthop add id 8 group 7\n # ip nexthop replace id 7 via 192.0.2.2 fdb\n Error: Cannot change nexthop FDB status while in a group.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 00000000000003c0\n[...]\nOops: Oops: 0000 [#1] SMP\nCPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:fib_lookup_good_nhc+0x1e/0x80\n[...]\nCall Trace:\n <TASK>\n fib_table_lookup+0x541/0x650\n ip_route_output_key_hash_rcu+0x2ea/0x970\n ip_route_output_key_hash+0x55/0x80\n __ip4_datagram_connect+0x250/0x330\n udp_connect+0x2b/0x60\n __sys_connect+0x9c/0xd0\n __x64_sys_connect+0x18/0x20\n do_syscall_64+0xa4/0x2a0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-39980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: Defer ip_vs_ftp unregister during netns cleanup\n\nOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp\nbefore connections with valid cp->app pointers are flushed, leading to a\nuse-after-free.\n\nFix this by introducing a global `exiting_module` flag, set to true in\nip_vs_ftp_exit() before unregistering the pernet subsystem. In\n__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns\ncleanup (when exiting_module is false) and defer it to\n__ip_vs_cleanup_batch(), which unregisters all apps after all connections\nare flushed. If called during module exit, unregister ip_vs_ftp\nimmediately.(CVE-2025-40018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs\n\nWhen the initialization of qm->debug.acc_diff_reg fails,\nthe probe process does not exit. However, after qm->debug.qm_diff_regs is\nfreed, it is not set to NULL. This can lead to a double free when the\nremove process attempts to free it again. Therefore, qm->debug.qm_diff_regs\nshould be set to NULL after it is freed.(CVE-2025-40062)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Explicitly check accesses to bpf_sock_addr\n\nSyzkaller found a kernel warning on the following sock_addr program:\n\n    0: r0 = 0\n    1: r2 = *(u32 *)(r1 +60)\n    2: exit\n\nwhich triggers:\n\n    verifier bug: error during ctx access conversion (0)\n\nThis is happening because offset 60 in bpf_sock_addr corresponds to an\nimplicit padding of 4 bytes, right after msg_src_ip4. Access to this\npadding isn't rejected in sock_addr_is_valid_access and it thus later\nfails to convert the access.\n\nThis patch fixes it by explicitly checking the various fields of\nbpf_sock_addr in sock_addr_is_valid_access.\n\nI checked the other ctx structures and is_valid_access functions and\ndidn't find any other similar cases. Other cases of (properly handled)\npadding are covered in new tests in a subsequent patch.(CVE-2025-40078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/qm - request reserved interrupt for virtual function\n\nThe device interrupt vector 3 is an error interrupt for\nphysical function and a reserved interrupt for virtual function.\nHowever, the driver has not registered the reserved interrupt for\nvirtual function. When allocating interrupts, the number of interrupts\nis allocated based on powers of two, which includes this interrupt.\nWhen the system enables GICv4 and the virtual function passthrough\nto the virtual machine, releasing the interrupt in the driver\ntriggers a warning.\n\nThe WARNING report is:\nWARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4\n\nTherefore, register a reserved interrupt for VF and set the\nIRQF_NO_AUTOEN flag to avoid that warning.(CVE-2025-40136)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: avoid NULL dereference when chunk data buffer is missing\n\nchunk->skb pointer is dereferenced in the if-block where it's supposed\nto be NULL only.\n\nchunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list\ninstead and do it just before replacing chunk->skb. We're sure that\notherwise chunk->skb is non-NULL because of outer if() condition.(CVE-2025-40240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: remove never-working support for setting nsh fields\n\nThe validation of the set(nsh(...)) action is completely wrong.\nIt runs through the nsh_key_put_from_nlattr() function that is the\nsame function that validates NSH keys for the flow match and the\npush_nsh() action.  However, the set(nsh(...)) has a very different\nmemory layout.  Nested attributes in there are doubled in size in\ncase of the masked set().  That makes proper validation impossible.\n\nThere is also confusion in the code between the 'masked' flag, that\nsays that the nested attributes are doubled in size containing both\nthe value and the mask, and the 'is_mask' that says that the value\nwe're parsing is the mask.  This is causing kernel crash on trying to\nwrite into mask part of the match with SW_FLOW_KEY_PUT() during\nvalidation, while validate_nsh() doesn't allocate any memory for it:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000018\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0\n  Oops: Oops: 0000 [#1] SMP NOPTI\n  CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary)\n  RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch]\n  Call Trace:\n   <TASK>\n   validate_nsh+0x60/0x90 [openvswitch]\n   validate_set.constprop.0+0x270/0x3c0 [openvswitch]\n   __ovs_nla_copy_actions+0x477/0x860 [openvswitch]\n   ovs_nla_copy_actions+0x8d/0x100 [openvswitch]\n   ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch]\n   genl_family_rcv_msg_doit+0xdb/0x130\n   genl_family_rcv_msg+0x14b/0x220\n   genl_rcv_msg+0x47/0xa0\n   netlink_rcv_skb+0x53/0x100\n   genl_rcv+0x24/0x40\n   netlink_unicast+0x280/0x3b0\n   netlink_sendmsg+0x1f7/0x430\n   ____sys_sendmsg+0x36b/0x3a0\n   ___sys_sendmsg+0x87/0xd0\n   __sys_sendmsg+0x6d/0xd0\n   do_syscall_64+0x7b/0x2c0\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe third issue with this process is that while trying to convert\nthe non-masked set into masked one, validate_set() copies and doubles\nthe size of the OVS_KEY_ATTR_NSH as if it didn't have any nested\nattributes.  It should be copying each nested attribute and doubling\nthem in size independently.  And the process must be properly reversed\nduring the conversion back from masked to a non-masked variant during\nthe flow dump.\n\nIn the end, the only two outcomes of trying to use this action are\neither validation failure or a kernel crash.  And if somehow someone\nmanages to install a flow with such an action, it will most definitely\nnot do what it is supposed to, since all the keys and the masks are\nmixed up.\n\nFixing all the issues is a complex task as it requires re-writing\nmost of the validation code.\n\nGiven that and the fact that this functionality never worked since\nintroduction, let's just remove it altogether.  It's better to\nre-introduce it later with a proper implementation instead of trying\nto fix it in stable releases.(CVE-2025-40254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free in tipc_mon_reinit_self().\n\nsyzbot reported use-after-free of tipc_net(net)->monitors[]\nin tipc_mon_reinit_self(). [0]\n\nThe array is protected by RTNL, but tipc_mon_reinit_self()\niterates over it without RTNL.\n\ntipc_mon_reinit_self() is called from tipc_net_finalize(),\nwhich is always under RTNL except for tipc_net_finalize_work().\n\nLet's hold RTNL in tipc_net_finalize_work().\n\n[0]:\nBUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\nBUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162\nRead of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989\n\nCPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025\nWorkqueue: events tipc_net_finalize_work\nCall Trace:\n <TASK>\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568\n kasan_check_byte include/linux/kasan.h:399 [inline]\n lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162\n rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline]\n rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline]\n rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244\n rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243\n write_lock_bh include/linux/rwlock_rt.h:99 [inline]\n tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718\n tipc_net_finalize+0x115/0x190 net/tipc/net.c:140\n process_one_work kernel/workqueue.c:3236 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400\n kthread+0x70e/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n </TASK>\n\nAllocated by task 6089:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657\n tipc_enable_bearer net/tipc/bearer.c:357 [inline]\n __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047\n __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline]\n tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393\n tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline]\n tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321\n genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:729\n ____sys_sendmsg+0x508/0x820 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/\n---truncated---(CVE-2025-40280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto\n\nsyzbot reported a possible shift-out-of-bounds [1]\n\nBlamed commit added rto_alpha_max and rto_beta_max set to 1000.\n\nIt is unclear if some sctp users are setting very large rto_alpha\nand/or rto_beta.\n\nIn order to prevent user regression, perform the test at run time.\n\nAlso add READ_ONCE() annotations as sysctl values can change under us.\n\n[1]\n\nUBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41\nshift exponent 64 is too large for 32-bit type 'unsigned int'\nCPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025\nCall Trace:\n <TASK>\n  __dump_stack lib/dump_stack.c:94 [inline]\n  dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n  ubsan_epilogue lib/ubsan.c:233 [inline]\n  __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494\n  sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509\n  sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502\n  sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338\n  sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline]\n  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline](CVE-2025-40281)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: Prevent TOCTOU out-of-bounds write\n\nFor the following path not holding the sock lock,\n\n  sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()\n\nmake sure not to exceed bounds in case the address list has grown\nbetween buffer allocation (time-of-check) and write (time-of-use).(CVE-2025-40331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: replace BUG_ON with bounds check for map->max_osd\n\nOSD indexes come from untrusted network packets. Boundary checks are\nadded to validate these against map->max_osd.\n\n[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic\n  edits ](CVE-2025-68283)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: prevent potential out-of-bounds writes in handle_auth_session_key()\n\nThe len field originates from untrusted network packets. Boundary\nchecks have been added to prevent potential out-of-bounds writes when\ndecrypting the connection secret or processing service tickets.\n\n[ idryomov: changelog ](CVE-2025-68284)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix potential use-after-free in have_mon_and_osd_map()\n\nThe wait loop in __ceph_open_session() can race with the client\nreceiving a new monmap or osdmap shortly after the initial map is\nreceived.  Both ceph_monc_handle_map() and handle_one_map() install\na new map immediately after freeing the old one\n\n    kfree(monc->monmap);\n    monc->monmap = monmap;\n\n    ceph_osdmap_destroy(osdc->osdmap);\n    osdc->osdmap = newmap;\n\nunder client->monc.mutex and client->osdc.lock respectively, but\nbecause neither is taken in have_mon_and_osd_map() it's possible for\nclient->monc.monmap->epoch and client->osdc.osdmap->epoch arms in\n\n    client->monc.monmap && client->monc.monmap->epoch &&\n        client->osdc.osdmap && client->osdc.osdmap->epoch;\n\ncondition to dereference an already freed map.  This happens to be\nreproducible with generic/395 and generic/397 with KASAN enabled:\n\n    BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70\n    Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305\n    CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266\n    ...\n    Call Trace:\n    <TASK>\n    have_mon_and_osd_map+0x56/0x70\n    ceph_open_session+0x182/0x290\n    ceph_get_tree+0x333/0x680\n    vfs_get_tree+0x49/0x180\n    do_new_mount+0x1a3/0x2d0\n    path_mount+0x6dd/0x730\n    do_mount+0x99/0xe0\n    __do_sys_mount+0x141/0x180\n    do_syscall_64+0x9f/0x100\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n    </TASK>\n\n    Allocated by task 13305:\n    ceph_osdmap_alloc+0x16/0x130\n    ceph_osdc_init+0x27a/0x4c0\n    ceph_create_client+0x153/0x190\n    create_fs_client+0x50/0x2a0\n    ceph_get_tree+0xff/0x680\n    vfs_get_tree+0x49/0x180\n    do_new_mount+0x1a3/0x2d0\n    path_mount+0x6dd/0x730\n    do_mount+0x99/0xe0\n    __do_sys_mount+0x141/0x180\n    do_syscall_64+0x9f/0x100\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n    Freed by task 9475:\n    kfree+0x212/0x290\n    handle_one_map+0x23c/0x3b0\n    ceph_osdc_handle_map+0x3c9/0x590\n    mon_dispatch+0x655/0x6f0\n    ceph_con_process_message+0xc3/0xe0\n    ceph_con_v1_try_read+0x614/0x760\n    ceph_con_workfn+0x2de/0x650\n    process_one_work+0x486/0x7c0\n    process_scheduled_works+0x73/0x90\n    worker_thread+0x1c8/0x2a0\n    kthread+0x2ec/0x300\n    ret_from_fork+0x24/0x40\n    ret_from_fork_asm+0x1a/0x30\n\nRewrite the wait loop to check the above condition directly with\nclient->monc.mutex and client->osdc.lock taken as appropriate.  While\nat it, improve the timeout handling (previously mount_timeout could be\nexceeded in case wait_event_interruptible_timeout() slept more than\nonce) and access client->auth_err under client->monc.mutex to match\nhow it's set in finish_auth().\n\nmonmap_show() and osdmap_show() now take the respective lock before\naccessing the map as well.(CVE-2025-68285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: lookup hci_conn on RX path on protocol side\n\nThe hdev lock/lookup/unlock/use pattern in the packet RX path doesn't\nensure hci_conn* is not concurrently modified/deleted. This locking\nappears to be leftover from before conn_hash started using RCU\ncommit bf4c63252490b ("Bluetooth: convert conn hash to RCU")\nand not clear if it had purpose since then.\n\nCurrently, there are code paths that delete hci_conn* from elsewhere\nthan the ordered hdev->workqueue where the RX work runs in. E.g.\ncommit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")\nintroduced some of these, and there probably were a few others before\nit.  It's better to do the locking so that even if these run\nconcurrently no UAF is possible.\n\nMove the lookup of hci_conn and associated socket-specific conn to\nprotocol recv handlers, and do them within a single critical section\nto cover hci_conn* usage and lookup.\n\nsyzkaller has reported a crash that appears to be this issue:\n\n    [Task hdev->workqueue]          [Task 2]\n                                    hci_disconnect_all_sync\n    l2cap_recv_acldata(hcon)\n                                      hci_conn_get(hcon)\n                                      hci_abort_conn_sync(hcon)\n                                        hci_dev_lock\n      hci_dev_lock\n                                        hci_conn_del(hcon)\n      v-------------------------------- hci_dev_unlock\n                                      hci_conn_put(hcon)\n      conn = hcon->l2cap_data (UAF)(CVE-2025-68304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nima: Handle error code returned by ima_filter_rule_match()\n\nIn ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to\nthe rule being NULL, the function incorrectly skips the 'if (!rc)' check\nand sets 'result = true'. The LSM rule is considered a match, causing\nextra files to be measured by IMA.\n\nThis issue can be reproduced in the following scenario:\nAfter unloading the SELinux policy module via 'semodule -d', if an IMA\nmeasurement is triggered before ima_lsm_rules is updated,\nin ima_match_rules(), the first call to ima_filter_rule_match() returns\n-ESTALE. This causes the code to enter the 'if (rc == -ESTALE &&\n!rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In\nima_lsm_copy_rule(), since the SELinux module has been removed, the rule\nbecomes NULL, and the second call to ima_filter_rule_match() returns\n-ENOENT. This bypasses the 'if (!rc)' check and results in a false match.\n\nCall trace:\n  selinux_audit_rule_match+0x310/0x3b8\n  security_audit_rule_match+0x60/0xa0\n  ima_match_rules+0x2e4/0x4a0\n  ima_match_policy+0x9c/0x1e8\n  ima_get_action+0x48/0x60\n  process_measurement+0xf8/0xa98\n  ima_bprm_check+0x98/0xd8\n  security_bprm_check+0x5c/0x78\n  search_binary_handler+0x6c/0x318\n  exec_binprm+0x58/0x1b8\n  bprm_execve+0xb8/0x130\n  do_execveat_common.isra.0+0x1a8/0x258\n  __arm64_sys_execve+0x48/0x68\n  invoke_syscall+0x50/0x128\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x44/0x200\n  el0t_64_sync_handler+0x100/0x130\n  el0t_64_sync+0x3c8/0x3d0\n\nFix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error\ncodes like -ENOENT do not bypass the check and accidentally result in a\nsuccessful match.(CVE-2025-68740)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix invalid prog->stats access when update_effective_progs fails\n\nSyzkaller triggers an invalid memory access issue following fault\ninjection in update_effective_progs. The issue can be described as\nfollows:\n\n__cgroup_bpf_detach\n  update_effective_progs\n    compute_effective_progs\n      bpf_prog_array_alloc <-- fault inject\n  purge_effective_progs\n    /* change to dummy_bpf_prog */\n    array->items[index] = &dummy_bpf_prog.prog\n\n---softirq start---\n__do_softirq\n  ...\n    __cgroup_bpf_run_filter_skb\n      __bpf_prog_run_save_cb\n        bpf_prog_run\n          stats = this_cpu_ptr(prog->stats)\n          /* invalid memory access */\n          flags = u64_stats_update_begin_irqsave(&stats->syncp)\n---softirq end---\n\n  static_branch_dec(&cgroup_bpf_enabled_key[atype])\n\nThe reason is that fault injection caused update_effective_progs to fail\nand then changed the original prog into dummy_bpf_prog.prog in\npurge_effective_progs. Then a softirq came, and accessing the members of\ndummy_bpf_prog.prog in the softirq triggers invalid mem access.\n\nTo fix it, skip updating stats when stats is NULL.(CVE-2025-68742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nethtool: Avoid overflowing userspace buffer on stats query\n\nThe ethtool -S command operates across three ioctl calls:\nETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, and\nETHTOOL_GSTATS for the values.\n\nIf the number of stats changes between these calls (e.g., due to device\nreconfiguration), userspace's buffer allocation will be incorrect,\npotentially leading to buffer overflow.\n\nDrivers are generally expected to maintain stable stat counts, but some\ndrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making\nthis scenario possible.\n\nSome drivers try to handle this internally:\n- bnad_get_ethtool_stats() returns early in case stats.n_stats is not\n  equal to the driver's stats count.\n- micrel/ksz884x also makes sure not to write anything beyond\n  stats.n_stats and overflow the buffer.\n\nHowever, both use stats.n_stats which is already assigned with the value\nreturned from get_sset_count(), hence won't solve the issue described\nhere.\n\nChange ethtool_get_strings(), ethtool_get_stats(),\nethtool_get_phy_stats() to not return anything in case of a mismatch\nbetween userspace's size and get_sset_size(), to prevent buffer\noverflow.\nThe returned n_stats value will be equal to zero, to reflect that\nnothing has been returned.\n\nThis could result in one of two cases when using upstream ethtool,\ndepending on when the size change is detected:\n1. When detected in ethtool_get_strings():\n    # ethtool -S eth2\n    no stats available\n\n2. When detected in get stats, all stats will be reported as zero.\n\nBoth cases are presumably transient, and a subsequent ethtool call\nshould succeed.\n\nOther than the overflow avoidance, these two cases are very evident (no\noutput/cleared stats), which is arguably better than presenting\nincorrect/shifted stats.\nI also considered returning an error instead of a "silent" response, but\nthat seems more destructive towards userspace apps.\n\nNotes:\n- This patch does not claim to fix the inherent race, it only makes sure\n  that we do not overflow the userspace buffer, and makes for a more\n  predictable behavior.\n\n- RTNL lock is held during each ioctl, the race window exists between\n  the separate ioctl calls when the lock is released.\n\n- Userspace ethtool always fills stats.n_stats, but it is likely that\n  these stats ioctls are implemented in other userspace applications\n  which might not fill it. The added code checks that it's not zero,\n  to prevent any regressions.(CVE-2025-68795)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: xattr: fix null pointer deref in ext4_raw_inode()\n\nIf ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),\niloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()\nlacks error checking, this will lead to a null pointer dereference\nin ext4_raw_inode(), called right after ext4_get_inode_loc().\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-68820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: using the num_tqps in the vf driver to apply for resources\n\nCurrently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqp\nis allocated using kinfo->num_tqps. However, kinfo->num_tqps is set to\nmin(new_tqps, hdev->num_tqps);  Therefore, kinfo->num_tqps may be smaller\nthan hdev->num_tqps, which causes some hdev->htqp[i] to remain\nuninitialized in hclgevf_knic_setup().\n\nThus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps,\nensuring that the lengths of hdev->htqp and kinfo->tqp are consistent\nand that all elements are properly initialized.(CVE-2025-71064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset\n\n`qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the class\nitself is active.\n\nTwo qfq_class objects may point to the same leaf_qdisc. This happens\nwhen:\n\n1. one QFQ qdisc is attached to the dev as the root qdisc, and\n\n2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()\n/ qdisc_put()) and is pending to be destroyed, as in function\ntc_new_tfilter.\n\nWhen packets are enqueued through the root QFQ qdisc, the shared\nleaf_qdisc->q.qlen increases. At the same time, the second QFQ\nqdisc triggers qdisc_put and qdisc_destroy: the qdisc enters\nqfq_reset() with its own q->q.qlen == 0, but its class's leaf\nqdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivate\nan inactive aggregate and trigger a null-deref in qfq_deactivate_agg:\n\n[    0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[    0.903571] #PF: supervisor write access in kernel mode\n[    0.903860] #PF: error_code(0x0002) - not-present page\n[    0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0\n[    0.904502] Oops: Oops: 0002 [#1] SMP NOPTI\n[    0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE\n[    0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n[    0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))\n[    0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0\n\nCode starting with the faulting instruction\n===========================================\n   0:\t0f 84 4d 01 00 00    \tje     0x153\n   6:\t48 89 70 18          \tmov    %rsi,0x18(%rax)\n   a:\t8b 4b 10             \tmov    0x10(%rbx),%ecx\n   d:\t48 c7 c2 ff ff ff ff \tmov    $0xffffffffffffffff,%rdx\n  14:\t48 8b 78 08          \tmov    0x8(%rax),%rdi\n  18:\t48 d3 e2             \tshl    %cl,%rdx\n  1b:\t48 21 f2             \tand    %rsi,%rdx\n  1e:\t48 2b 13             \tsub    (%rbx),%rdx\n  21:\t48 8b 30             \tmov    (%rax),%rsi\n  24:\t48 d3 ea             \tshr    %cl,%rdx\n  27:\t8b 4b 18             \tmov    0x18(%rbx),%ecx\n\t...\n[    0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246\n[    0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000\n[    0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[    0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000\n[    0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000\n[    0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880\n[    0.909179] FS:  000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000\n[    0.909572] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0\n[    0.910247] PKRU: 55555554\n[    0.910391] Call Trace:\n[    0.910527]  <TASK>\n[    0.910638]  qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)\n[    0.910826]  qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)\n[    0.911040]  __qdisc_destroy (net/sched/sch_generic.c:1076)\n[    0.911236]  tc_new_tfilter (net/sched/cls_api.c:2447)\n[    0.911447]  rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\n[    0.911663]  ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)\n[    0.911894]  netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n[    0.912100]  netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n[    0.912296]  ? __alloc_skb (net/core/skbuff.c:706)\n[    0.912484]  netlink_sendmsg (net/netlink/af\n---truncated---(CVE-2026-22976)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix reference count leak in bpf_prog_test_run_xdp()\n\nsyzbot is reporting\n\n  unregister_netdevice: waiting for sit0 to become free. Usage count = 2\n\nproblem. A debug printk() patch found that a refcount is obtained at\nxdp_convert_md_to_buff() from bpf_prog_test_run_xdp().\n\nAccording to commit ec94670fcb3b ("bpf: Support specifying ingress via\nxdp_md context in BPF_PROG_TEST_RUN"), the refcount obtained by\nxdp_convert_md_to_buff() will be released by xdp_convert_buff_to_md().\n\nTherefore, we can consider that the error handling path introduced by\ncommit 1c1949982524 ("bpf: introduce frags support to\nbpf_prog_test_run_xdp()") forgot to call xdp_convert_buff_to_md().(CVE-2026-22994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a deadlock involving nfs_release_folio()\n\nWang Zhaolong reports a deadlock involving NFSv4.1 state recovery\nwaiting on kthreadd, which is attempting to reclaim memory by calling\nnfs_release_folio(). The latter cannot make progress due to state\nrecovery being needed.\n\nIt seems that the only safe thing to do here is to kick off a writeback\nof the folio, without waiting for completion, or else kicking off an\nasynchronous commit.(CVE-2026-23053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-core: fix wrong reinitialization of ringbuffer on reopen\n\ndvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the\nDVR device.  dvb_ringbuffer_init() calls init_waitqueue_head(), which\nreinitializes the waitqueue list head to empty.\n\nSince dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the\nsame DVR device share it), this orphans any existing waitqueue entries\nfrom io_uring poll or epoll, leaving them with stale prev/next pointers\nwhile the list head is reset to {self, self}.\n\nThe waitqueue and spinlock in dvr_buffer are already properly\ninitialized once in dvb_dmxdev_init().  The open path only needs to\nreset the buffer data pointer, size, and read/write positions.\n\nReplace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct\nassignment of data/size and a call to dvb_ringbuffer_reset(), which\nproperly resets pread, pwrite, and error with correct memory ordering\nwithout touching the waitqueue or spinlock.(CVE-2026-23253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregmap: maple: free entry on mas_store_gfp() failure\n\nregcache_maple_write() allocates a new block ('entry') to merge\nadjacent ranges and then stores it with mas_store_gfp().\nWhen mas_store_gfp() fails, the new 'entry' remains allocated and\nis never freed, leaking memory.\n\nFree 'entry' on the failure path; on success continue freeing the\nreplaced neighbor blocks ('lower', 'upper').(CVE-2026-23260)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix unprivileged local user can do privileged policy management\n\nAn unprivileged local user can load, replace, and remove profiles by\nopening the apparmorfs interfaces, via a confused deputy attack, by\npassing the opened fd to a privileged process, and getting the\nprivileged process to write to the interface.\n\nThis does require a privileged target that can be manipulated to do\nthe write for the unprivileged process, but once such access is\nachieved full policy management is possible and all the possible\nimplications that implies: removing confinement, DoS of system or\ntarget applications by denying all execution, by-passing the\nunprivileged user namespace restriction, to exploiting kernel bugs for\na local privilege escalation.\n\nThe policy management interface can not have its permissions simply\nchanged from 0666 to 0600 because non-root processes need to be able\nto load policy to different policy namespaces.\n\nInstead ensure the task writing the interface has privileges that\nare a subset of the task that opened the interface. This is already\ndone via policy for confined processes, but unconfined can delegate\naccess to the opened fd, by-passing the usual policy check.(CVE-2026-23268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix __perf_event_overflow() vs perf_remove_from_context() race\n\nMake sure that __perf_event_overflow() runs with IRQs disabled for all\npossible callchains. Specifically the software events can end up running\nit with only preemption disabled.\n\nThis opens up a race vs perf_event_exit_event() and friends that will go\nand free various things the overflow path expects to be present, like\nthe BPF program.(CVE-2026-23271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: observe an RCU grace period in macvlan_common_newlink() error path\n\nvalis reported that a race condition still happens after my prior patch.\n\nmacvlan_common_newlink() might have made @dev visible before\ndetecting an error, and its caller will directly call free_netdev(dev).\n\nWe must respect an RCU period, either in macvlan or the core networking\nstack.\n\nAfter adding a temporary mdelay(1000) in macvlan_forward_source_one()\nto open the race window, valis repro was:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\nip link add mv0 link p2 type macvlan mode source\n\n(ip link add invalid% link p2 type macvlan mode source macaddr add\n00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4\nPING 1.2.3.4 (1.2.3.4): 56 data bytes\nRTNETLINK answers: Invalid argument\n\nBUG: KASAN: slab-use-after-free in macvlan_forward_source\n(drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nRead of size 8 at addr ffff888016bb89c0 by task e/175\n\nCPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n<IRQ>\ndump_stack_lvl (lib/dump_stack.c:123)\nprint_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nkasan_report (mm/kasan/report.c:597)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nmacvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\n? tasklet_init (kernel/softirq.c:983)\nmacvlan_handle_frame (drivers/net/macvlan.c:501)\n\nAllocated by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\n__kasan_kmalloc (mm/kasan/common.c:419)\n__kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657\nmm/slub.c:7140)\nalloc_netdev_mqs (net/core/dev.c:12012)\nrtnl_create_link (net/core/rtnetlink.c:3648)\nrtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)\n\nFreed by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\nkasan_save_free_info (mm/kasan/generic.c:587)\n__kasan_slab_free (mm/kasan/common.c:287)\nkfree (mm/slub.c:6674 mm/slub.c:6882)\nrtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)(CVE-2026-23273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Fix recursive locking in __configfs_open_file()\n\nIn flush_write_buffer, &p->frag_sem is acquired and then the loaded store\nfunction is called, which, here, is target_core_item_dbroot_store().  This\nfunction called filp_open(), following which these functions were called\n(in reverse order), according to the call trace:\n\n  down_read\n  __configfs_open_file\n  do_dentry_open\n  vfs_open\n  do_open\n  path_openat\n  do_filp_open\n  file_open_name\n  filp_open\n  target_core_item_dbroot_store\n  flush_write_buffer\n  configfs_write_iter\n\ntarget_core_item_dbroot_store() tries to validate the new file path by\ntrying to open the file path provided to it; however, in this case, the bug\nreport shows:\n\ndb_root: not a directory: /sys/kernel/config/target/dbroot\n\nindicating that the same configfs file was tried to be opened, on which it\nis currently working on. Thus, it is trying to acquire frag_sem semaphore\nof the same file of which it already holds the semaphore obtained in\nflush_write_buffer(), leading to acquiring the semaphore in a nested manner\nand a possibility of recursive locking.\n\nFix this by modifying target_core_item_dbroot_store() to use kern_path()\ninstead of filp_open() to avoid opening the file using filesystem-specific\nfunction __configfs_open_file(), and further modifying it to make this fix\ncompatible.(CVE-2026-23292)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Fix refcount leak for tagset_refcnt\n\nThis leak will cause a hang when tearing down the SCSI host. For example,\niscsid hangs with the following call trace:\n\n[130120.652718] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured\n\nPID: 2528     TASK: ffff9d0408974e00  CPU: 3    COMMAND: "iscsid"\n #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4\n #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f\n #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0\n #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f\n #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b\n #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp]\n #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi]\n #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi]\n #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6\n #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef(CVE-2026-23296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix preempt count leak in napi poll tracepoint\n\nUsing get_cpu() in the tracepoint assignment causes an obvious preempt\ncount leak because nothing invokes put_cpu() to undo it:\n\n  softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?\n\nThis clearly has seen a lot of testing in the last 3+ years...\n\nUse smp_processor_id() instead.(CVE-2026-23313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Return the correct value in vmw_translate_ptr functions\n\nBefore the referenced fixes these functions used a lookup function that\nreturned a pointer. This was changed to another lookup function that\nreturned an error code with the pointer becoming an out parameter.\n\nThe error path when the lookup failed was not changed to reflect this\nchange and the code continued to return the PTR_ERR of the now\nuninitialized pointer. This could cause the vmw_translate_ptr functions\nto return success when they actually failed causing further uninitialized\nand OOB accesses.(CVE-2026-23317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim\n\nThe root cause of this bug is that when 'bpf_link_put' reduces the\nrefcount of 'shim_link->link.link' to zero, the resource is considered\nreleased but may still be referenced via 'tr->progs_hlist' in\n'cgroup_shim_find'. The actual cleanup of 'tr->progs_hlist' in\n'bpf_shim_tramp_link_release' is deferred. During this window, another\nprocess can cause a use-after-free via 'bpf_trampoline_link_cgroup_shim'.\n\nBased on Martin KaFai Lau's suggestions, I have created a simple patch.\n\nTo fix this:\n   Add an atomic non-zero check in 'bpf_trampoline_link_cgroup_shim'.\n   Only increment the refcount if it is not already zero.\n\nTesting:\n   I verified the fix by adding a delay in\n   'bpf_shim_tramp_link_release' to make the bug easier to trigger:\n\nstatic void bpf_shim_tramp_link_release(struct bpf_link *link)\n{\n\t/* ... */\n\tif (!shim_link->trampoline)\n\t\treturn;\n\n+\tmsleep(100);\n\tWARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link,\n\t\tshim_link->trampoline, NULL));\n\tbpf_trampoline_put(shim_link->trampoline);\n}\n\nBefore the patch, running a PoC easily reproduced the crash(almost 100%)\nwith a call trace similar to KaiyanM's report.\nAfter the patch, the bug no longer occurs even after millions of\niterations.(CVE-2026-23319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/efi: defer freeing of boot services memory\n\nefi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE\nand EFI_BOOT_SERVICES_DATA using memblock_free_late().\n\nThere are two issue with that: memblock_free_late() should be used for\nmemory allocated with memblock_alloc() while the memory reserved with\nmemblock_reserve() should be freed with free_reserved_area().\n\nMore acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y\nefi_free_boot_services() is called before deferred initialization of the\nmemory map is complete.\n\nBenjamin Herrenschmidt reports that this causes a leak of ~140MB of\nRAM on EC2 t3a.nano instances which only have 512MB or RAM.\n\nIf the freed memory resides in the areas that memory map for them is\nstill uninitialized, they won't be actually freed because\nmemblock_free_late() calls memblock_free_pages() and the latter skips\nuninitialized pages.\n\nUsing free_reserved_area() at this point is also problematic because\n__free_page() accesses the buddy of the freed page and that again might\nend up in uninitialized part of the memory map.\n\nDelaying the entire efi_free_boot_services() could be problematic\nbecause in addition to freeing boot services memory it updates\nefi.memmap without any synchronization and that's undesirable late in\nboot when there is concurrency.\n\nMore robust approach is to only defer freeing of the EFI boot services\nmemory.\n\nSplit efi_free_boot_services() in two. First efi_unmap_boot_services()\ncollects ranges that should be freed into an array then\nefi_free_boot_services() later frees them after deferred init is complete.(CVE-2026-23352)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix stack-out-of-bounds write in devmap\n\nget_upper_ifindexes() iterates over all upper devices and writes their\nindices into an array without checking bounds.\n\nAlso the callers assume that the max number of upper devices is\nMAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack,\nbut that assumption is not correct and the number of upper devices could\nbe larger than MAX_NEST_DEV (e.g., many macvlans), causing a\nstack-out-of-bounds write.\n\nAdd a max parameter to get_upper_ifindexes() to avoid the issue.\nWhen there are too many upper devices, return -EOVERFLOW and abort the\nredirect.\n\nTo reproduce, create more than MAX_NEST_DEV(8) macvlans on a device with\nan XDP program attached using BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS.\nThen send a packet to the device to trigger the XDP redirect path.(CVE-2026-23359)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix admin queue leak on controller reset\n\nWhen nvme_alloc_admin_tag_set() is called during a controller reset,\na previous admin queue may still exist. Release it properly before\nallocating a new one to avoid orphaning the old queue.\n\nThis fixes a regression introduced by commit 03b3bcd319b3 ("nvme: fix\nadmin request_queue lifetime").(CVE-2026-23360)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblktrace: fix __this_cpu_read/write in preemptible context\n\ntracing_record_cmdline() internally uses __this_cpu_read() and\n__this_cpu_write() on the per-CPU variable trace_cmdline_save, and\ntrace_save_cmdline() explicitly asserts preemption is disabled via\nlockdep_assert_preemption_disabled(). These operations are only safe\nwhen preemption is off, as they were designed to be called from the\nscheduler context (probe_wakeup_sched_switch() / probe_wakeup()).\n\n__blk_add_trace() was calling tracing_record_cmdline(current) early in\nthe blk_tracer path, before ring buffer reservation, from process\ncontext where preemption is fully enabled. This triggers the following\nusing blktests/blktrace/002:\n\nblktrace/002 (blktrace ftrace corruption with sysfs trace)   [failed]\n    runtime  0.367s  ...  0.437s\n    something found in dmesg:\n    [   81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33\n    [   81.239580] null_blk: disk nullb1 created\n    [   81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516\n    [   81.362842] caller is tracing_record_cmdline+0x10/0x40\n    [   81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G                 N  7.0.0-rc1lblk+ #84 PREEMPT(full)\n    [   81.362877] Tainted: [N]=TEST\n    [   81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n    [   81.362881] Call Trace:\n    [   81.362884]  <TASK>\n    [   81.362886]  dump_stack_lvl+0x8d/0xb0\n    ...\n    (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)\n\n[   81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33\n[   81.239580] null_blk: disk nullb1 created\n[   81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516\n[   81.362842] caller is tracing_record_cmdline+0x10/0x40\n[   81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G                 N  7.0.0-rc1lblk+ #84 PREEMPT(full)\n[   81.362877] Tainted: [N]=TEST\n[   81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n[   81.362881] Call Trace:\n[   81.362884]  <TASK>\n[   81.362886]  dump_stack_lvl+0x8d/0xb0\n[   81.362895]  check_preemption_disabled+0xce/0xe0\n[   81.362902]  tracing_record_cmdline+0x10/0x40\n[   81.362923]  __blk_add_trace+0x307/0x5d0\n[   81.362934]  ? lock_acquire+0xe0/0x300\n[   81.362940]  ? iov_iter_extract_pages+0x101/0xa30\n[   81.362959]  blk_add_trace_bio+0x106/0x1e0\n[   81.362968]  submit_bio_noacct_nocheck+0x24b/0x3a0\n[   81.362979]  ? lockdep_init_map_type+0x58/0x260\n[   81.362988]  submit_bio_wait+0x56/0x90\n[   81.363009]  __blkdev_direct_IO_simple+0x16c/0x250\n[   81.363026]  ? __pfx_submit_bio_wait_endio+0x10/0x10\n[   81.363038]  ? rcu_read_lock_any_held+0x73/0xa0\n[   81.363051]  blkdev_read_iter+0xc1/0x140\n[   81.363059]  vfs_read+0x20b/0x330\n[   81.363083]  ksys_read+0x67/0xe0\n[   81.363090]  do_syscall_64+0xbf/0xf00\n[   81.363102]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   81.363106] RIP: 0033:0x7f281906029d\n[   81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec\n[   81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[   81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d\n[   81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000\n[   81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000\n[   81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000\n[   81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a\n[   81.363142]  </TASK>\n\nThe same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(),\nand blk_add_trace_rq() paths as well.\n\nThe purpose of tracin\n---truncated---(CVE-2026-23374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing\n\nstruct bpf_plt contains a u64 target field. Currently, the BPF JIT\nallocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT\nbuffer.\n\nBecause the base address of the JIT buffer can be 4-byte aligned (e.g.,\nending in 0x4 or 0xc), the relative padding logic in build_plt() fails\nto ensure that target lands on an 8-byte boundary.\n\nThis leads to two issues:\n1. UBSAN reports misaligned-access warnings when dereferencing the\n   structure.\n2. More critically, target is updated concurrently via WRITE_ONCE() in\n   bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64,\n   64-bit loads/stores are only guaranteed to be single-copy atomic if\n   they are 64-bit aligned. A misaligned target risks a torn read,\n   causing the JIT to jump to a corrupted address.\n\nFix this by increasing the allocation alignment requirement to 8 bytes\n(sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of\nthe JIT buffer to an 8-byte boundary, allowing the relative padding math\nin build_plt() to correctly align the target field.(CVE-2026-23383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSquashfs: check metadata block offset is within range\n\nSyzkaller reports a "general protection fault in squashfs_copy_data"\n\nThis is ultimately caused by a corrupted index look-up table, which\nproduces a negative metadata block offset.\n\nThis is subsequently passed to squashfs_copy_data (via\nsquashfs_read_metadata) where the negative offset causes an out of bounds\naccess.\n\nThe fix is to check that the offset is within range in\nsquashfs_read_metadata.  This will trap this and other cases.(CVE-2026-23388)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: reject mount if bigalloc with s_first_data_block != 0\n\nbigalloc with s_first_data_block != 0 is not supported, reject mounting\nit.(CVE-2026-31447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Check to ensure report responses match the request\n\nIt is possible for a malicious (or clumsy) device to respond to a\nspecific report's feature request using a completely different report\nID.  This can cause confusion in the HID core resulting in nasty\nside-effects such as OOB writes.\n\nAdd a check to ensure that the report ID in the response, matches the\none that was requested.  If it doesn't, omit reporting the raw event and\nreturn early.(CVE-2026-43047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Mitigate potential OOB by removing bogus memset()\n\nThe memset() in hid_report_raw_event() has the good intention of\nclearing out bogus data by zeroing the area from the end of the incoming\ndata string to the assumed end of the buffer.  However, as we have\npreviously seen, doing so can easily result in OOB reads and writes in\nthe subsequent thread of execution.\n\nThe current suggestion from one of the HID maintainers is to remove the\nmemset() and simply return if the incoming event buffer size is not\nlarge enough to fill the associated report.\n\nSuggested-by Benjamin Tissoires <(CVE-2026-43048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: close crash window in attr dabtree inactivation\n\nWhen inactivating an inode with node-format extended attributes,\nxfs_attr3_node_inactive() invalidates all child leaf/node blocks via\nxfs_trans_binval(), but intentionally does not remove the corresponding\nentries from their parent node blocks.  The implicit assumption is that\nxfs_attr_inactive() will truncate the entire attr fork to zero extents\nafterwards, so log recovery will never reach the root node and follow\nthose stale pointers.\n\nHowever, if a log shutdown occurs after the leaf/node block cancellations\ncommit but before the attr bmap truncation commits, this assumption\nbreaks.  Recovery replays the attr bmap intact (the inode still has\nattr fork extents), but suppresses replay of all cancelled leaf/node\nblocks, maybe leaving them as stale data on disk.  On the next mount,\nxlog_recover_process_iunlinks() retries inactivation and attempts to\nread the root node via the attr bmap. If the root node was not replayed,\nreading the unreplayed root block triggers a metadata verification\nfailure immediately; if it was replayed, following its child pointers\nto unreplayed child blocks triggers the same failure:\n\n XFS (pmem0): Metadata corruption detected at\n xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78\n XFS (pmem0): Unmount and run xfs_repair\n XFS (pmem0): First 128 bytes of corrupted metadata buffer:\n 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117\n\nFix this in two places:\n\nIn xfs_attr3_node_inactive(), after calling xfs_trans_binval() on a\nchild block, immediately remove the entry that references it from the\nparent node in the same transaction.  This eliminates the window where\nthe parent holds a pointer to a cancelled block.  Once all children are\nremoved, the now-empty root node is converted to a leaf block within the\nsame transaction. This node-to-leaf conversion is necessary for crash\nsafety. If the system shutdown after the empty node is written to the\nlog but before the second-phase bmap truncation commits, log recovery\nwill attempt to verify the root block on disk. xfs_da3_node_verify()\ndoes not permit a node block with count == 0; such a block will fail\nverification and trigger a metadata corruption shutdown. on the other\nhand, leaf blocks are allowed to have this transient state.\n\nIn xfs_attr_inactive(), split the attr fork truncation into two explicit\nphases.  First, truncate all extents beyond the root block (the child\nextents whose parent references have already been removed above).\nSecond, invalidate the root block and truncate the attr bmap to zero in\na single transaction.  The two operations in the second phase must be\natomic: as long as the attr bmap has any non-zero length, recovery can\nfollow it to the root block, so the root block invalidation must commit\ntogether with the bmap-to-zero truncation.(CVE-2026-43053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"\n\nThis reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking\nwhen enabling/disabling SR-IOV"), which causes a deadlock by recursively\ntaking pci_rescan_remove_lock when sriov_del_vfs() is called as part of\npci_stop_and_remove_bus_device(). For example with the following sequence\nof commands:\n\n  $ echo <NUM> > /sys/bus/pci/devices/<pf>/sriov_numvfs\n  $ echo 1 > /sys/bus/pci/devices/<pf>/remove\n\nA trimmed trace of the deadlock on a mlx5 device is as below:\n\n  zsh/5715 is trying to acquire lock:\n  000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140\n\n  but task is already holding lock:\n  000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80\n  ...\n  Call Trace:\n   [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110\n   [<00000259779c844e>] print_deadlock_bug+0x31e/0x330\n   [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0\n   [<00000259779bffac>] lock_acquire+0x14c/0x350\n   [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520\n   [<000002597896413c>] mutex_lock_nested+0x3c/0x50\n   [<00000259784a07e4>] sriov_disable+0x34/0x140\n   [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core]\n   [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core]\n   [<00000259784857fc>] pci_device_remove+0x3c/0xa0\n   [<000002597851012e>] device_release_driver_internal+0x18e/0x280\n   [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0\n   [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80\n   [<00000259784972c2>] remove_store+0x72/0x90\n   [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200\n   [<0000025977d7241c>] vfs_write+0x24c/0x300\n   [<0000025977d72696>] ksys_write+0x86/0x110\n   [<000002597895b61c>] __do_syscall+0x14c/0x400\n   [<000002597896e0ee>] system_call+0x6e/0x90\n\nThis alone is not a complete fix as it restores the issue the cited commit\ntried to solve. A new fix will be provided as a follow on.(CVE-2026-43147)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: Add support for TSV110 Spectre-BHB mitigation\n\nThe TSV110 processor is vulnerable to the Spectre-BHB (Branch History\nBuffer) attack, which can be exploited to leak information through\nbranch prediction side channels. This commit adds the MIDR of TSV110\nto the list for software mitigation.(CVE-2026-43261)\n\nIn the Linux kernel, the kexec_load_purgatory() function derives image->start by locating e_entry inside an SHF_EXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN. Derive the entry section from the purgatory_start symbol when present and compute image->start from its final placement. Keep the existing e_entry fallback for purgatories that do not expose the symbol.(CVE-2026-43289)\n\nIn the Linux kernel, there is a potential out-of-bounds access vulnerability in the ceph_handle_auth_reply() function of the libceph component. When processing messages of type CEPH_MSG_AUTH_REPLY, the value of the payload_len field is stored in a variable of type int. A value greater than INT_MAX leads to integer overflow and is interpreted as a negative value, which causes the pointer address to be decremented and subsequently accessed because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. The vulnerability is fixed by changing the data type of payload_len to u32 and introducing additional sanity checks.(CVE-2026-43407)\n\nIn the Linux kernel, when an alias is found through d_splice_alias in the nfs3_proc_create function, if the alias happens to be a directory dentry, the system does not return any error but simply forgets about this alias, leaving the original dentry to be added as negative. This later causes a system crash in nfs_atomic_open_v23/finish_open since a negative dentry is supplied to do_dentry_open. This issue was observed running lustre-racer, where directories and files are created/removed concurrently with the same name and O_EXCL is not used to open files.(CVE-2026-43470)","modified":"2026-05-22T13:30:23.334105112Z","published":"2026-05-22T13:21:30Z","upstream":["CVE-2024-56611","CVE-2024-56760","CVE-2025-21908","CVE-2025-21931","CVE-2025-21970","CVE-2025-21971","CVE-2025-21980","CVE-2025-21981","CVE-2025-21986","CVE-2025-21995","CVE-2025-22001","CVE-2025-22009","CVE-2025-22071","CVE-2025-22077","CVE-2025-23138","CVE-2025-23157","CVE-2025-37740","CVE-2025-37748","CVE-2025-37766","CVE-2025-37768","CVE-2025-37770","CVE-2025-37771","CVE-2025-37778","CVE-2025-37793","CVE-2025-37805","CVE-2025-37815","CVE-2025-37831","CVE-2025-37844","CVE-2025-37853","CVE-2025-37881","CVE-2025-37889","CVE-2025-37905","CVE-2025-37918","CVE-2025-37947","CVE-2025-37967","CVE-2025-38014","CVE-2025-38037","CVE-2025-38043","CVE-2025-38051","CVE-2025-38064","CVE-2025-38113","CVE-2025-38122","CVE-2025-38123","CVE-2025-38131","CVE-2025-38148","CVE-2025-38161","CVE-2025-38183","CVE-2025-38193","CVE-2025-38194","CVE-2025-38241","CVE-2025-38255","CVE-2025-38304","CVE-2025-38307","CVE-2025-38321","CVE-2025-38344","CVE-2025-38364","CVE-2025-38461","CVE-2025-38462","CVE-2025-38488","CVE-2025-38499","CVE-2025-38552","CVE-2025-38575","CVE-2025-38609","CVE-2025-38721","CVE-2025-39676","CVE-2025-39682","CVE-2025-39702","CVE-2025-39728","CVE-2025-39756","CVE-2025-39770","CVE-2025-39812","CVE-2025-39841","CVE-2025-39894","CVE-2025-39937","CVE-2025-39955","CVE-2025-39980","CVE-2025-40018","CVE-2025-40062","CVE-2025-40078","CVE-2025-40136","CVE-2025-40240","CVE-2025-40254","CVE-2025-40280","CVE-2025-40281","CVE-2025-40331","CVE-2025-68283","CVE-2025-68284","CVE-2025-68285","CVE-2025-68304","CVE-2025-68740","CVE-2025-68742","CVE-2025-68795","CVE-2025-68820","CVE-2025-71064","CVE-2026-22976","CVE-2026-22994","CVE-2026-23053","CVE-2026-23253","CVE-2026-23260","CVE-2026-23268","CVE-2026-23271","CVE-2026-23273","CVE-2026-23292","CVE-2026-23296","CVE-2026-23313","CVE-2026-23317","CVE-2026-23319","CVE-2026-23352","CVE-2026-23359","CVE-2026-23360","CVE-2026-23374","CVE-2026-23383","CVE-2026-23388","CVE-2026-31447","CVE-2026-43047","CVE-2026-43048","CVE-2026-43053","CVE-2026-43147","CVE-2026-43261","CVE-2026-43289","CVE-2026-43407","CVE-2026-43470"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2418"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56611"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56760"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21908"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21931"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21970"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21971"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21980"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21986"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21995"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22001"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22009"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22071"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22077"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23138"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23157"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37740"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37748"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37766"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37768"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37770"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37771"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37778"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37793"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37805"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37815"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37831"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37844"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37853"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37881"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37889"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37905"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37918"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37947"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37967"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38014"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38037"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38043"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38051"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38064"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38113"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38122"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38123"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38131"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38148"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38161"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38183"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38193"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38194"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38241"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38255"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38304"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38307"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38321"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38344"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38364"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38461"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38462"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38488"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38499"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38552"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38575"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38609"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38721"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39676"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39682"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39702"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39728"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39756"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39770"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39812"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39841"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39894"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39937"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39955"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39980"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40018"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40062"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40078"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40136"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40240"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40254"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40280"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40281"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40331"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68283"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68284"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68285"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68304"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68740"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68742"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68795"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68820"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71064"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22976"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22994"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23253"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23260"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23268"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23271"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23273"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23292"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23296"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23319"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23352"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23359"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23360"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23374"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23383"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23388"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31447"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43047"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43048"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43147"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43261"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43289"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43407"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43470"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP1","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.1.12.150.oe2403sp1"}]}],"ecosystem_specific":{"src":["kernel-6.6.0-145.1.12.150.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","kernel-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","perf-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.1.12.150.oe2403sp1.x86_64.rpm"],"aarch64":["bpftool-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","kernel-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","perf-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.1.12.150.oe2403sp1.aarch64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-2418.json"}}],"schema_version":"1.7.5"}