The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

mISDN: hfcpci: Fix warning when deleting uninitialized timer

With CONFIGDEBUGOBJECTS_TIMERS unloading hfcpci module leads to the following splat:

[ 250.215892] ODEBUG: assertinit not available (active state 0) object: ffffffffc01a3dc0 object type: timerlist hint: 0x0 [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debugprintobject+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDNcore [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary) [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 250.222377] RIP: 0010:debugprintobject+0x1b6/0x2c0 [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286 [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0 [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39 [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001 [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8 [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000 [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0 [ 250.236117] Call Trace: [ 250.236599] <TASK> [ 250.236967] ? traceirqenable.constprop.0+0xd4/0x130 [ 250.237920] debugobjectassertinit+0x1f6/0x310 [ 250.238762] ? __pfxdebugobjectassertinit+0x10/0x10 [ 250.239658] ? __lock_acquire+0xdea/0x1c70 [ 250.240369] __trytolock_acquire+0xdea/0x1c70 [ 250.240369] __trytodeltimersync+0x69/0x140 [ 250.241172] ? pfxrytodeltimersync+0x10/0x10 [ 250.242058] ? __timerdeletesync+0xc6/0x120 [ 250.242842] ? lock_acquire+0x30/0x80 [ 250.243474] ? __timerdeletesync+0xc6/0x120 [ 250.244262] __timerdeletesync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] _dosystimerdeletesync+0xc6/0x120 [ 250.244262] __timerdeletesync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] _dosysdeletemodule+0x348/0x510 [ 250.246461] ? pfxosysdeletemodule+0x10/0x10 [ 250.247338] dosyscall64+0xc1/0x360 [ 250.247924] entrySYSCALL64afterhwframe+0x77/0x7f

Fix this by initializing hfctl timer with DEFINETIMER macro. Also, use mod_timer instead of manual timeout update.(CVE-2025-39833)

In the Linux kernel, the following vulnerability has been resolved:

platform/x86/amd/pmc: Add support for Van Gogh SoC

The ROG Xbox Ally (non-X) SoC features a similar architecture to the Steam Deck. While the Steam Deck supports S3 (s2idle causes a crash), this support was dropped by the Xbox Ally which only S0ix suspend.

Since the handler is missing here, this causes the device to not suspend and the AMD GPU driver to crash while trying to resume afterwards due to a power hang.(CVE-2025-68334)

In the Linux kernel, the following vulnerability has been resolved:

team: Move team device type change at the end of teamportadd

Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops.

In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that headerops->create of team0 is changed from ethheader to ipgreheader in the call to teamdevtypecheck_change.

Later when we end up in ipgreheader() struct iptunnel* points to nonsense as the private data of the device still holds a struct team.

Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1

Move teamdevtypecheckchange down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail.

Also make sure to preserve the origial mtu assignment: - If portdev is not the same type as dev, dev takes mtu from portdev - If portdev is the same type as dev, portdev takes mtu from dev

This is done by adding a conditional before the call to devsetmtu to prevent it from assigning portdev->mtu = dev->mtu and instead letting teamdevtypecheckchange assign dev->mtu = portdev->mtu. The conditional is needed because the patch moves the call to teamdevtypecheckchange past devsetmtu.

Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot(CVE-2025-68340)

In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_router: Fix neighbour use-after-free

We sometimes observe use-after-free when dereferencing a neighbour [1]. The problem seems to be that the driver stores a pointer to the neighbour, but without holding a reference on it. A reference is only taken when the neighbour is used by a nexthop.

Fix by simplifying the reference counting scheme. Always take a reference when storing a neighbour pointer in a neighbour entry. Avoid taking a referencing when the neighbour is used by a nexthop as the neighbour entry associated with the nexthop already holds a reference.

Tested by running the test that uncovered the problem over 300 times. Without this patch the problem was reproduced after a handful of iterations.

[1] BUG: KASAN: slab-use-after-free in mlxswspneighentryupdate+0x2d4/0x310 Read of size 8 at addr ffff88817f8e3420 by task ip/3929

CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full) Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 Call Trace: <TASK> dumpstacklvl+0x6f/0xa0 printaddressdescription.constprop.0+0x6e/0x300 printreport+0xfc/0x1fb kasanreport+0xe4/0x110 mlxswspneighentryupdate+0x2d4/0x310 mlxswsprouterrifgonesync+0x35f/0x510 mlxswsprifdestroy+0x1ea/0x730 mlxswspinetaddrportvlan_event+0xa1/0x1b0 __mlxswspinetaddrlagevent+0xcc/0x130 __mlxswspinetaddrevent+0xf5/0x3c0 mlxswsprouternetdeviceevent+0x1015/0x1580 notifiercallchain+0xcc/0x150 callnetdevicenotifiersinfo+0x7e/0x100 __netdevupperdevunlink+0x10b/0x210 netdevupperdevunlink+0x79/0xa0 vrfdelslave+0x18/0x50 dosetmaster+0x146/0x7d0 dosetlink.isra.0+0x9a0/0x2880 rtnlnewlink+0x637/0xb20 rtnetlinkrcvmsg+0x6fe/0xb90 netlinkrcvskb+0x123/0x380 netlinkunicast+0x4a3/0x770 netlinksendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 ____sys_sendmsg+0x5b2/0x7d0 ___sys_sendmsg+0xfd/0x180 _syssendmsg+0x124/0x1c0 dosyscall64+0xbb/0xfd0 entrySYSCALL64afterhwframe+0x4b/0x53 [...]

Allocated by task 109: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmallocnoprof+0x2c1/0x790 neighalloc+0x6af/0x8f0 __neighcreate+0x63/0xe90 mlxswspnexthopneighinit+0x430/0x7e0 mlxswspnexthoptypeinit+0x212/0x960 mlxswspnexthop6groupinfoinit.constprop.0+0x81f/0x1280 mlxswspnexthop6groupget+0x392/0x6a0 mlxswspfib6entrycreate+0x46a/0xfd0 mlxswsprouterfib6replace+0x1ed/0x5f0 mlxswsprouterfib6eventwork+0x10a/0x2a0 processonework+0xd57/0x1390 workerthread+0x4d6/0xd40 kthread+0x355/0x5b0 retfromfork+0x1d4/0x270 retfromforkasm+0x11/0x20

Freed by task 154: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 __kasansavefree_info+0x3b/0x60 _kasanslabfree+0x43/0x70 kmemcachefreebulk.part.0+0x1eb/0x5e0 kvfreercubulk+0x1f2/0x260 kfreercuwork+0x130/0x1b0 processonework+0xd57/0x1390 workerthread+0x4d6/0xd40 kthread+0x355/0x5b0 retfromfork+0x1d4/0x270 retfromforkasm+0x11/0x20

Last potentially related work creation: kasansavestack+0x30/0x50 kasanrecordauxstack+0x8c/0xa0 kvfreecallrcu+0x93/0x5b0 mlxswsprouterneigheventwork+0x67d/0x860 processonework+0xd57/0x1390 workerthread+0x4d6/0xd40 kthread+0x355/0x5b0 retfromfork+0x1d4/0x270 retfromforkasm+0x11/0x20(CVE-2025-68801)

In the Linux kernel, the following vulnerability has been resolved:

svcrdma: bound check rq_pages index in inline path

svcrdmacopyinlinerange indexed rqstp->rqpages[rccurpage] without verifying rc_curpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.(CVE-2025-71068)

In the Linux kernel, the following vulnerability has been resolved:

iavf: fix off-by-one issues in iavfconfigrss_reg()

There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.

Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were: i <= I40EVFQF{HKEY,HLUT}MAXINDEX which is safe since the value is the last valid index.

That commit changed the bounds to: i <= adapter->rss_{key,lut}_size / 4 where rss_{key,lut}_size / 4 is the number of dwords, so the last valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <= accesses one element past the end.

Fix the issues by using < instead of <=, ensuring we do not exceed the bounds.

[1] KASAN splat about rsskeysize off-by-one BUG: KASAN: slab-out-of-bounds in iavfconfigrss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63

CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavfwatchdogtask Call Trace: <TASK> dumpstacklvl+0x6f/0xb0 printreport+0x170/0x4f3 kasanreport+0xe1/0x1a0 iavfconfigrss+0x619/0x800 iavfwatchdogtask+0x2be7/0x3230 processonework+0x7fd/0x1420 workerthread+0x4d1/0xd40 kthread+0x344/0x660 retfromfork+0x249/0x320 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 63: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 __kasan_kmalloc+0x7f/0x90 _kmallocnoprof+0x246/0x6f0 iavfwatchdogtask+0x28fc/0x3230 processonework+0x7fd/0x1420 workerthread+0x4d1/0xd40 kthread+0x344/0x660 retfromfork+0x249/0x320 retfromforkasm+0x1a/0x30

The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134)

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)

In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gem: Zero-initialize the eb.vma array in i915gemdo_execbuffer

Initialize the eb.vma array with values of 0 when the eb structure is first set up. In particular, this sets the eb->vma[i].vma pointers to NULL, simplifying cleanup and getting rid of the bug described below.

During the execution of eblookupvmas(), the eb->vma array is successively filled up with struct ebvma objects. This process includes calling ebadd_vma(), which might fail; however, even in the event of failure, eb->vma[i].vma is set for the currently processed buffer.

If ebaddvma() fails, eblookupvmas() returns with an error, which prompts a call to ebreleasevmas() to clean up the mess. Since eblookupvmas() might fail during processing any (possibly not first) buffer, ebreleasevmas() checks whether a buffer's vma is NULL to know at what point did the lookup function fail.

In eblookupvmas(), eb->vma[i].vma is set to NULL if either the helper function eblookupvma() or ebvalidatevma() fails. eb->vma[i+1].vma is set to NULL in case i915gemobjectuserptrsubmitinit() fails; the current one needs to be cleaned up by ebreleasevmas() at this point, so the next one is set. If ebadd_vma() fails, neither the current nor the next vma is set to NULL, which is a source of a NULL deref bug described in the issue linked in the Closes tag.

When entering eblookupvmas(), the vma pointers are set to the slab poison value, instead of NULL. This doesn't matter for the actual lookup, since it gets overwritten anyway, however the ebreleasevmas() function only recognizes NULL as the stopping value, hence the pointers are being set to NULL as they go in case of intermediate failure. This patch changes the approach to filling them all with NULL at the start instead, rather than handling that manually during failure.

(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)(CVE-2025-71130)

In the Linux kernel, the following vulnerability has been resolved:

net: dsa: properly keep track of conduit reference

Problem description

DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.

There are two distinct problems.

1. The OF path, which uses offindnetdevicebynode(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsadevtonetdevice() has a putdevice() call which is missing in dsaportparseof(), but we can actually even verify that an issue exists. With CONFIGDEBUGKOBJECTRELEASE=y, if we run this command "before" and "after" applying this patch:

(unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind

we see these lines in the output diff which appear only with the patch applied:

kobject: 'eno2' (ffff002009a3a6b8): kobjectrelease, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobjectrelease, parent 0000000000000000 (delayed 1000)

2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpudp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (devhold() and dev_put()).

Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdevupperdevlink(). But time still passes at DSA switch probe time between the initial offindnetdevicebynode() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it.

So we have to run offindnetdevicebynode() under rtnllock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference.

Do we need to keep the reference until dsaunregisterswitch() / dsaswitchshutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpudp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsatreefindfirst_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.

As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself.

History and blame attribution

The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct.

We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---(CVE-2025-71152)

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix deadlock in waitcurrenttrans() due to ignored transaction type

When waitcurrenttrans() is called during starttransaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfsblockedtranstypes[] array already defines which transaction types should wait for which transaction states, but this check was missing in waitcurrenttrans().

This can lead to a deadlock scenario involving two transactions and pending ordered extents:

1. Transaction A is in TRANSSTATECOMMIT_DOING state

2. A worker processing an ordered extent calls starttransaction() with TRANSJOIN

3. jointransaction() returns -EBUSY because Transaction A is in TRANSSTATECOMMITDOING

4. Transaction A moves to TRANSSTATEUNBLOCKED and completes

5. A new Transaction B is created (TRANSSTATERUNNING)

6. The ordered extent from step 2 is added to Transaction B's pending ordered extents

7. Transaction B immediately starts commit by another task and enters TRANSSTATECOMMIT_START

8. The worker finally reaches waitcurrenttrans(), sees Transaction B in TRANSSTATECOMMIT_START (a blocked state), and waits unconditionally

9. However, TRANSJOIN should NOT wait for TRANSSTATECOMMITSTART according to btrfsblockedtrans_types[]

10. Transaction B is waiting for pending ordered extents to complete

11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B

This can be illustrated by the following call stacks: CPU0 CPU1 btrfsfinishorderedio() starttransaction(TRANSJOIN) jointransaction() # -EBUSY (Transaction A is # TRANSSTATECOMMITDOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfscommittransaction() # Transaction B enters # TRANSSTATECOMMITSTART # waiting for pending ordered # extents waitcurrenttrans() # waits for Transaction B # (should not wait!)

Task bstorekvsync in btrfscommittransaction waiting for ordered extents:

__schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfscommittransaction+0xbf7/0xda0 [btrfs] btrfssyncfile+0x342/0x4d0 [btrfs] __x64sysfdatasync+0x4b/0x80 dosyscall64+0x33/0x40 entrySYSCALL64afterhwframe+0x44/0xa9

Task kworker in waitcurrenttrans waiting for transaction commit:

Workqueue: btrfs-synonocow btrfswork_helper [btrfs] _schedule+0x2e7/0x8a0 schedule+0x64/0xe0 waitcurrenttrans+0xb0/0x110 [btrfs] starttransaction+0x346/0x5b0 [btrfs] btrfsfinishorderedio.isra.0+0x49b/0x9c0 [btrfs] btrfsworkhelper+0xe8/0x350 [btrfs] processonework+0x1d3/0x3c0 workerthread+0x4d/0x3e0 kthread+0x12d/0x150 retfromfork+0x1f/0x30

Fix this by passing the transaction type to waitcurrenttrans() and checking btrfsblockedtranstypes[curtrans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.(CVE-2025-71194)

In the Linux kernel, the following vulnerability has been resolved:

macvlan: fix possible UAF in macvlanforwardsource()

Add RCU protection on (struct macvlansourceentry)->vlan.

Whenever macvlanhashdel_source() is called, we must clear entry->vlan pointer before RCU grace period starts.

This allows macvlanforwardsource() to skip over entries queued for freeing.

Note that macvlandev are already RCU protected, as they are embedded in a standard netdev (netdevpriv(ndev)).

https: //lore.kernel.org/netdev/(CVE-2026-23001)

In the Linux kernel, the following vulnerability has been resolved:

ipv4: ipgre: make ipgreheader() robust

Analog to commit db5b4e39c4e6 ("ip6gre: make ip6greheader() robust")

Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1].

This involves team or bonding drivers ability to dynamically change their dev->neededheadroom and/or dev->hardheader_len

In this particular crash mldnewpack() allocated an skb with a too small reserve/headroom, and by the time mldsendpack() was called, syzbot managed to attach an ipgre device.

[1] skbuff: skbunderpanic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mldifcwork RIP: 0010:skbpanic+0x157/0x160 net/core/skbuff.c:213 Call Trace: <TASK> skbunderpanic net/core/skbuff.c:223 [inline] skbpush+0xc3/0xe0 net/core/skbuff.c:2641 ipgreheader+0x67/0x290 net/ipv4/ipgre.c:897 devhardheader include/linux/netdevice.h:3436 [inline] neighconnectedoutput+0x286/0x460 net/core/neighbour.c:1618 NFHOOKCOND include/linux/netfilter.h:307 [inline] ip6output+0x340/0x550 net/ipv6/ip6output.c:247 NFHOOK+0x9e/0x380 include/linux/netfilter.h:318 mldsendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mldsendcr net/ipv6/mcast.c:2154 [inline] mldifcwork+0x83e/0xd60 net/ipv6/mcast.c:2693 processonework kernel/workqueue.c:3257 [inline] processscheduledworks+0xad1/0x1770 kernel/workqueue.c:3340 workerthread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 retfromfork+0x510/0xa50 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:246(CVE-2026-23011)

In the Linux kernel, the following vulnerability has been resolved:

mm/page_alloc: prevent pcp corruption with SMP=n

The kernel test robot has reported:

BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: <IRQ> __dumpstack (lib/dumpstack.c:95) dumpstacklvl (lib/dumpstack.c:123) dumpstack (lib/dumpstack.c:130) spindump (kernel/locking/spinlockdebug.c:71) dorawspintrylock (kernel/locking/spinlockdebug.c:?) rawspintrylock (include/linux/spinlockapismp.h:89 kernel/locking/spinlock.c:138) __freefrozenpages (mm/page_alloc.c:2973) ___freepages (mm/pagealloc.c:5295) __freepages (mm/pagealloc.c:5334) tlbremovetablercu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmugather.c:227 mm/mmu_gather.c:290) ? __cfitlbremovetablercu (mm/mmugather.c:289) ? rcucore (kernel/rcu/tree.c:?) rcucore (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcucoresi (kernel/rcu/tree.c:2879) handlesoftirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irqexitrcu (arch/x86/include/asm/jumplabel.h:36 kernel/softirq.c:725) irqexitrcu (kernel/softirq.c:741) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1052) </IRQ> <TASK> RIP: 0010:rawspinunlockirqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlockapismp.h:152 kernel/locking/spinlock.c:194) freepcppagesbulk (mm/pagealloc.c:1494) drainpageszone (include/linux/spinlock.h:391 mm/pagealloc.c:2632) __drainallpages (mm/pagealloc.c:2731) drainallpages (mm/pagealloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfikthread (kernel/kthread.c:412) retfrom_fork (arch/x86/kernel/process.c:164) ? _cfikthread (kernel/kthread.c:412) retfromforkasm (arch/x86/entry/entry64.S:255) </TASK>

Matthew has analyzed the report and identified that in drainpagezone() we are in a section protected by spinlock(&pcp->lock) and then get an interrupt that attempts spintrylock() on the same lock. The code is designed to work this way without disabling IRQs and occasionally fail the trylock with a fallback. However, the SMP=n spinlock implementation assumes spin_trylock() will always succeed, and thus it's normally a no-op. Here the enabled lock debugging catches the problem, but otherwise it could cause a corruption of the pcp structure.

The problem has been introduced by commit 574907741599 ("mm/pagealloc: leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spintrylock() sections on SMP=n, but the need to prevent the nesting in spinlock() has not been recognized. Fix it by introducing local wrappers that change the spinlock() to spinlockiqsave() with SMP=n and use them in all places that do spin_lock(&pcp->lock).

[(CVE-2026-23025)

In the Linux kernel, the following vulnerability has been resolved:

net: hv_netvsc: reject RSS hash key programming without RX indirection table

RSS configuration requires a valid RX indirection table. When the device reports a single receive queue, rndisfilterdevice_add() does not allocate an indirection table, accepting RSS hash key updates in this state leads to a hang.

Fix this by gating netvscsetrxfh() on ndc->rxtablesz and return -EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device capabilities and prevents incorrect behavior.(CVE-2026-23054)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: Enforce that teql can only be used as root qdisc

Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.

Although not important, I will describe the scenario that unearthed this issue for the curious.

GangMin Kim <(CVE-2026-23074)

In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: fix hugetlbpmdshared()

Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)", v3.

One functional fix, one performance regression fix, and two related comment fixes.

I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things.

The goal of this patch set is to be backported to stable trees "fairly" easily. At least patch #1 and #4.

Patch #1 fixes hugetlbpmdshared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit().

The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated

There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series.

Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86.

This patch (of 4):

We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->ptsharecount to identify sharing.

We didn't convert hugetlbpmdshared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table.

Page migration, like mbind() or migratepages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PMMMAP_EXCLUSIVE in the pagemap interface.

Fix it by properly using ptdescpmdisshared() in hugetlbpmd_shared().(CVE-2026-23100)

In the Linux kernel, the following vulnerability has been resolved:

tracing: Add recursion protection in kernel stack trace recording

A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again.

Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI).

Have the stack trace code use the interrupt context to protect against recursion.

Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately.(CVE-2026-23138)

In the Linux kernel, the following vulnerability has been resolved:

tcp: secure_seq: add back ports to TS offset

This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")

tcptwrecycle went away in 2017.

Zhouyan Deng reported off-path TCP source port leakage via SYN cookie side-channel that can be fixed in multiple ways.

One of them is to bring back TCP ports in TS offset randomization.

As a bonus, we perform a single siphash() computation to provide both an ISN and a TS offset.(CVE-2026-23247)

In the Linux kernel, a vulnerability exists in the AppArmor module's unpack_pdb function. The vulnerability occurs due to failure to validate that DFA start states are within bounds, which can lead to out-of-bound reads. An attacker can exploit this vulnerability through specially crafted policy files, potentially leading to information disclosure or system crashes.(CVE-2026-23269)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: unconditionally bump set->nelems before insertion

In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already.

To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state.

As for element updates, decrement set->nelems to restore it.

A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.(CVE-2026-23272)

In the Linux kernel, the following vulnerability has been resolved:

net: usb: kaweth: validate USB endpoints

The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.(CVE-2026-23312)

In the Linux kernel, the following vulnerability has been resolved:

net: sched: avoid qdiscresetalltxgt() vs dequeue race for lockless qdiscs

When shrinking the number of real tx queues, netifsetrealnumtxqueues() calls qdiscresetalltx_gt() to flush qdiscs for queues which will no longer be used.

qdiscresetalltxgt() currently serializes qdiscreset() with qdisclock(). However, for lockless qdiscs, the dequeue path is serialized by qdiscrunbegin/end() using qdisc->seqlock instead, so qdisc_reset() can run concurrently with _qdiscrun() and free skbs while they are still being dequeued, leading to UAF.

This can easily be reproduced on e.g. virtio-net by imposing heavy traffic while frequently changing the number of queue pairs:

iperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0 combined 1 ethtool -L eth0 combined 2 done

With KASAN enabled, this leads to reports like:

BUG: KASAN: slab-use-after-free in __qdisc_run+0x133f/0x1760 ... Call Trace: <TASK> ... __qdisc_run+0x133f/0x1760 __devqueuexmit+0x248f/0x3550 ipfinishoutput2+0xa42/0x2110 ipoutput+0x1a7/0x410 ipsendskb+0x2e6/0x480 udpsendskb+0xb0a/0x1590 udpsendmsg+0x13c9/0x1fc0 ... </TASK>

Allocated by task 1270 on cpu 5 at 44.558414s: ... allocskbwithfrags+0x84/0x7c0 sockallocsendpskb+0x69a/0x830 _ipappenddata+0x1b86/0x48c0 ipmakeskb+0x1e8/0x2b0 udpsendmsg+0x13a6/0x1fc0 ...

Freed by task 1306 on cpu 3 at 44.558445s: ... kmemcachefree+0x117/0x5e0 pfifofastreset+0x14d/0x580 qdiscreset+0x9e/0x5f0 netifsetrealnumtxqueues+0x303/0x840 virtnetsetchannels+0x1bf/0x260 [virtionet] ethnlsetchannels+0x684/0xae0 ethnldefaultsetdoit+0x31a/0x890 ...

Serialize qdiscresetalltxgt() against the lockless dequeue path by taking qdisc->seqlock for TCQFNOLOCK qdiscs, matching the serialization model already used by devresetqueue().

Additionally clear QDISCSTATENON_EMPTY after reset so the qdisc state reflects an empty queue, avoiding needless re-scheduling.(CVE-2026-23340)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_ife: Fix metalist update behavior

Whenever an ife action replace changes the metalist, instead of replacing the old data on the metalist, the current ife code is appending the new metadata. Aside from being innapropriate behavior, this may lead to an unbounded addition of metadata to the metalist which might cause an out of bounds error when running the encode op:

[ 138.423369][ C1] ================================================================== [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ifetlvmetaencode (net/ife/ife.c:168) [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ifeoutoutbou/255 [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ifeoutoutbou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full) [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 138.425800][ C1] Call Trace: [ 138.425804][ C1] <IRQ> [ 138.425808][ C1] dumpstacklvl (lib/dumpstack.c:122) [ 138.425828][ C1] printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 138.425839][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] ? __virtaddrvalid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1)) [ 138.425853][ C1] ? ife_tlvmetaencode (net/ife/ife.c:168) [ 138.425859][ C1] kasanreport (mm/kasan/report.c:221 mm/kasan/report.c:597) [ 138.425868][ C1] ? ifetlvmetaencode (net/ife/ife.c:168) [ 138.425878][ C1] kasancheckrange (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1)) [ 138.425884][ C1] __asanmemset (mm/kasan/shadow.c:84 (discriminator 2)) [ 138.425889][ C1] ifetlvmetaencode (net/ife/ife.c:168) [ 138.425893][ C1] ? ifetlvmetaencode (net/ife/ife.c:171) [ 138.425898][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ifeencodemetau16 (net/sched/actife.c:57) [ 138.425910][ C1] ? __pfxdorawspinlock (kernel/locking/spinlock_debug.c:114) [ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105 (discriminator 3)) [ 138.425921][ C1] ? __pfxifeencodemetau16 (net/sched/actife.c:45) [ 138.425927][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcfifeact (net/sched/actife.c:847 net/sched/actife.c:879)

To solve this issue, fix the replace behavior by adding the metalist to the ife rcu data structure.(CVE-2026-23378)

In the Linux kernel, the following vulnerability has been resolved:

ice: Fix memory leak in icesetringparam()

In icesetringparam, txrings and xdprings are allocated before rxrings. If the allocation of rxrings fails, the code jumps to the done label leaking both txrings and xdprings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the freetx label which releases txrings but leaks xdp_rings.

Fix this by introducing a freexdp label and updating the error paths to ensure both xdprings and txrings are properly freed if rxrings allocation or setup fails.

Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-23389)

In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix side-effect bug in match_char() macro usage

The match_char() macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the DFA to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary.

[ 94.984676] ================================================================== [ 94.985301] BUG: KASAN: slab-out-of-bounds in aadfamatch+0x5ae/0x760 [ 94.985655] Read of size 1 at addr ffff888100342000 by task file/976

[ 94.986319] CPU: 7 UID: 1000 PID: 976 Comm: file Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 94.986322] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 94.986329] Call Trace: [ 94.986341] <TASK> [ 94.986347] dumpstacklvl+0x5e/0x80 [ 94.986374] printreport+0xc8/0x270 [ 94.986384] ? aadfamatch+0x5ae/0x760 [ 94.986388] kasanreport+0x118/0x150 [ 94.986401] ? aadfamatch+0x5ae/0x760 [ 94.986405] aadfamatch+0x5ae/0x760 [ 94.986408] __aapathperm+0x131/0x400 [ 94.986418] aa_pathperm+0x219/0x2f0 [ 94.986424] apparmorfileopen+0x345/0x570 [ 94.986431] securityfileopen+0x5c/0x140 [ 94.986442] dodentryopen+0x2f6/0x1120 [ 94.986450] vfsopen+0x38/0x2b0 [ 94.986453] ? mayopen+0x1e2/0x2b0 [ 94.986466] pathopenat+0x231b/0x2b30 [ 94.986469] ? __x64sysopenat+0xf8/0x130 [ 94.986477] dofileopen+0x19d/0x360 [ 94.986487] dosysopenat2+0x98/0x100 [ 94.986491] __x64sysopenat+0xf8/0x130 [ 94.986499] dosyscall64+0x8e/0x660 [ 94.986515] ? countmemcgevents+0x15f/0x3c0 [ 94.986526] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 94.986540] ? handlemmfault+0x1639/0x1ef0 [ 94.986551] ? vmastartread+0xf0/0x320 [ 94.986558] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 94.986561] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 94.986563] ? fpregsassertstateconsistent+0x50/0xe0 [ 94.986572] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 94.986574] ? archexittousermodeprepare+0x9/0xb0 [ 94.986587] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 94.986588] ? irqentryexit+0x3c/0x590 [ 94.986595] entrySYSCALL64afterhwframe+0x76/0x7e [ 94.986597] RIP: 0033:0x7fda4a79c3ea

Fix by extracting the character value before invoking match_char, ensuring single evaluation per outer loop.(CVE-2026-23406)

In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix missing bounds check on DEFAULT table in verify_dfa()

The verifydfa() function only checks DEFAULTTABLE bounds when the state is not differentially encoded.

When the verification loop traverses the differential encoding chain, it reads k = DEFAULTTABLE[j] and uses k as an array index without validation. A malformed DFA with DEFAULTTABLE[j] >= state_count, therefore, causes both out-of-bounds reads and writes.

[ 57.179855] ================================================================== [ 57.180549] BUG: KASAN: slab-out-of-bounds in verify_dfa+0x59a/0x660 [ 57.180904] Read of size 4 at addr ffff888100eadec4 by task su/993

[ 57.181554] CPU: 1 UID: 0 PID: 993 Comm: su Not tainted 6.19.0-rc7-next-20260127 #1 PREEMPT(lazy) [ 57.181558] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 57.181563] Call Trace: [ 57.181572] <TASK> [ 57.181577] dumpstacklvl+0x5e/0x80 [ 57.181596] printreport+0xc8/0x270 [ 57.181605] ? verifydfa+0x59a/0x660 [ 57.181608] kasanreport+0x118/0x150 [ 57.181620] ? verifydfa+0x59a/0x660 [ 57.181623] verifydfa+0x59a/0x660 [ 57.181627] aadfa_unpack+0x1610/0x1740 [ 57.181629] ? __kmalloccachenoprof+0x1d0/0x470 [ 57.181640] unpackpdb+0x86d/0x46b0 [ 57.181647] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 57.181653] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 57.181656] ? aaunpacknameX+0x1a8/0x300 [ 57.181659] aaunpack+0x20b0/0x4c30 [ 57.181662] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 57.181664] ? stackdepotsaveflags+0x33/0x700 [ 57.181681] ? kasansavetrack+0x4f/0x80 [ 57.181683] ? kasansavetrack+0x3e/0x80 [ 57.181686] ? __kasan_kmalloc+0x93/0xb0 [ 57.181688] ? __kvmallocnodenoprof+0x44a/0x780 [ 57.181693] ? aasimplewritetobuffer+0x54/0x130 [ 57.181697] ? policyupdate+0x154/0x330 [ 57.181704] aareplaceprofiles+0x15a/0x1dd0 [ 57.181707] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 57.181710] ? __kvmallocnodenoprof+0x44a/0x780 [ 57.181712] ? aaloaddataalloc+0x77/0x140 [ 57.181715] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 57.181717] ? copyfromuser+0x2a/0x70 [ 57.181730] policyupdate+0x17a/0x330 [ 57.181733] profilereplace+0x153/0x1a0 [ 57.181735] ? rwverifyarea+0x93/0x2d0 [ 57.181740] vfswrite+0x235/0xab0 [ 57.181745] ksyswrite+0xb0/0x170 [ 57.181748] dosyscall64+0x8e/0x660 [ 57.181762] entrySYSCALL64afterhwframe+0x76/0x7e [ 57.181765] RIP: 0033:0x7f6192792eb2

Remove the MATCHFLAGDIFFENCODE condition to validate all DEFAULTTABLE entries unconditionally.(CVE-2026-23407)

A race condition vulnerability exists in the AppArmor security module of the Linux kernel, leading to a use-after-free issue. This vulnerability can be triggered when an attacker simultaneously opens rawdata files and removes an associated AppArmor profile. Since rawdata inodes are not refcounted, there is a time window during profile removal where the i_private pointer may reference freed memory, causing the system to access freed memory regions. This can result in program crashes, unexpected value usage, or arbitrary code execution, threatening the confidentiality, integrity, and availability of the system.(CVE-2026-23410)

A vulnerability exists in the AppArmor security module of the Linux kernel when handling the iprivate field of the inode structure. AppArmor was putting the reference to iprivate data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs callback functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. This vulnerability could allow a local attacker to bypass AppArmor's access control policies through a specially crafted request, leading to privilege escalation and impacting system confidentiality, integrity, and availability.(CVE-2026-23411)

In the Linux kernel, the following vulnerability has been resolved:

udptunnel: fix NULL deref caused by udpsockcreate6 when CONFIGIPV6=n

When CONFIGIPV6 is disabled, the udpsockcreate6() function returns 0 (success) without actually creating a socket. Callers such as foucreate() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference.

The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:founladddoit (net/ipv4/foucore.c:590 net/ipv4/foucore.c:764) [...] Call Trace: <TASK> genlfamilyrcvmsgdoit.constprop.0 (net/netlink/genetlink.c:1114) genlrcvmsg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlinkrcvskb (net/netlink/afnetlink.c:2550) genlrcv (net/netlink/genetlink.c:1219) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) _x64syssendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) entrySYSCALL64afterhwframe (net/arch/x86/entry/entry64.S:130)

This patch makes udpsockcreate6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.(CVE-2026-23439)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix race condition during IPSec ESN update

In IPSec full offload mode, the device reports an ESN (Extended Sequence Number) wrap event to the driver. The driver validates this event by querying the IPSec ASO and checking that the esneventarm field is 0x0, which indicates an event has occurred. After handling the event, the driver must re-arm the context by setting esneventarm back to 0x1.

A race condition exists in this handling path. After validating the event, the driver calls mlx5accelespmodifyxfrm() to update the kernel's xfrm state. This function temporarily releases and re-acquires the xfrm state lock.

So, need to acknowledge the event first by setting esneventarm to 0x1. This prevents the driver from reprocessing the same ESN update if the hardware sends events for other reason. Since the next ESN update only occurs after nearly 2^31 packets are received, there's no risk of missing an update, as it will happen long after this handling has finished.

Processing the event twice causes the ESN high-order bits (esn_msb) to be incremented incorrectly. The driver then programs the hardware with this invalid ESN state, which leads to anti-replay failures and a complete halt of IPSec traffic.

Fix this by re-arming the ESN event immediately after it is validated, before calling mlx5accelespmodifyxfrm(). This ensures that any spurious, duplicate events are correctly ignored, closing the race window.(CVE-2026-23440)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Prevent concurrent access to IPSec ASO context

The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5eipsecaso struct for each PF, which contains a shared DMA-mapped context for all ASO operations.

A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area.

When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results.

This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained.(CVE-2026-23441)

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: always free skb on ieee80211txprepare_skb() failure

ieee80211txprepareskb() has three error paths, but only two of them free the skb. The first error path (ieee80211txprepare() returning TXDROP) does not free it, while invoketxhandlers() failure and the fragmentation check both do.

Add kfreeskb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211hwsim) to avoid double-free.

Document the skb ownership guarantee in the function's kdoc.(CVE-2026-23444)

In the Linux kernel, the following vulnerability has been resolved:

net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check

cdcncmrxverifyndp16() validates that the NDP header and its DPE entries fit within the skb. The first check correctly accounts for ndpoffset:

if ((ndpoffset + sizeof(struct usbcdcncmndp16)) > skbin->len)

but the second check omits it:

if ((sizeof(struct usbcdcncmndp16) + ret * (sizeof(struct usbcdcncmdpe16))) > skb_in->len)

This validates the DPE array size against the total skb length as if the NDP were at offset 0, rather than at ndpoffset. When the NDP is placed near the end of the NTB (large wNdpIndex), the DPE entries can extend past the skb data buffer even though the check passes. cdcncmrx_fixup() then reads out-of-bounds memory when iterating the DPE array.

Add ndpoffset to the nframes bounds check and use structsizet() to express the NDP-plus-DPE-array size more clearly.(CVE-2026-23448)

In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix NULL dereference and UAF in smctcpsynrecvsock()

Syzkaller reported a panic in smctcpsynrecvsock() [1].

smctcpsynrecvsock() is called in the TCP receive path (softirq) via icskafops->synrecvsock on the clcsock (TCP listening socket). It reads skuserdata to get the smcsock pointer. However, when the SMC listen socket is being closed concurrently, smccloseactive() sets clcsock->skuserdata to NULL under skcallbacklock, and then the smcsock itself can be freed via sockput() in smcrelease().

This leads to two issues:

1) NULL pointer dereference: skuserdata is NULL when accessed. 2) Use-after-free: skuserdata is read as non-NULL, but the smcsock is freed before its fields (e.g., queuedsmchs, oriaf_ops) are accessed.

The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcpgetcookiesock() -> smctcpsynrecvsock(), but the normal tcpcheck_req() path has the same race):

CPU A (softirq) CPU B (process ctx)

tcpv4rcv() TCPNEWSYNRECV: sk = req->rsklistener sockhold(sk) /* No lock on listener */ smccloseactive(): writelockbh(cblock) skuserdata = NULL writeunlockbh(cblock) ... smcclcsockrelease() sockput(smc->sk) x2 -> smcsock freed! tcpcheckreq() smctcpsynrecvsock(): smc = userdata(sk) -> NULL or dangling smc->queuedsmchs -> crash!

Note that the clcsock and smcsock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smcsock from being freed.

Fix this by using RCU and refcountincnotzero() to safely access smcsock. Since smctcpsynrecvsock() is called in the TCP three-way handshake path, taking readlockbh on skcallbacklock is too heavy and would not survive a SYN flood attack. Using rcureadlock() is much more lightweight.

• Set SOCKRCUFREE on the SMC listen socket so that smcsock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcuread_lock().
• Use rcureadlock() to protect reading skuserdata.
• Use refcountincnotzero(&smc->sk.skrefcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.

Note: smchscongested() has a similar lockless read of skuserdata without rcureadlock(), but it only checks for NULL and accesses the global smchswq, never dereferencing any smc_sock field, so it is not affected.

Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied.

[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9(CVE-2026-23450)

In the Linux kernel, the following vulnerability has been resolved:

PM: runtime: Fix a race condition related to device removal

The following code in pmruntimework() may dereference the dev->parent pointer after the parent device has been freed:

/* Maybe the parent is now able to suspend. */
if (parent && !parent->power.ignore_children) {
    spin_unlock(&dev->power.lock);

    spin_lock(&parent->power.lock);
    rpm_idle(parent, RPM_ASYNC);
    spin_unlock(&parent->power.lock);

    spin_lock(&dev->power.lock);
}

Fix this by inserting a flushwork() call in pmruntime_remove().

Without this patch blktest block/001 triggers the following complaint sporadically:

BUG: KASAN: slab-use-after-free in lockacquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pmruntimework Call Trace: <TASK> dumpstacklvl+0x61/0x80 printaddressdescription.constprop.0+0x8b/0x310 printreport+0xfd/0x1d7 kasan_report+0xd8/0x1d0 _kasancheckbyte+0x42/0x60 lockacquire.part.0+0x38/0x230 lockacquire+0x70/0x160 rawspinlock+0x36/0x50 rpmsuspend+0xc6a/0xfe0 rpmidle+0x578/0x770 pmruntimework+0xee/0x120 processonework+0xde3/0x1410 workerthread+0x5eb/0xfe0 kthread+0x37b/0x480 retfromfork+0x6cb/0x920 retfromforkasm+0x11/0x20 </TASK>

Allocated by task 4314: kasansavestack+0x2a/0x50 kasansavetrack+0x18/0x40 kasansavealloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmallocnoprof+0x311/0x990 scsialloctarget+0x122/0xb60 [scsimod] __scsiscantarget+0x101/0x460 [scsimod] scsiscan_channel+0x179/0x1c0 [scsimod] scsiscanhostselected+0x259/0x2d0 [scsimod] storescan+0x2d2/0x390 [scsimod] devattrstore+0x43/0x80 sysfskfwrite+0xde/0x140 kernfsfopwriteiter+0x3ef/0x670 vfswrite+0x506/0x1470 ksyswrite+0xfd/0x230 __x64syswrite+0x76/0xc0 x64syscall+0x213/0x1810 dosyscall64+0xee/0xfc0 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 4314: kasansavestack+0x2a/0x50 kasansavetrack+0x18/0x40 kasansavefree_info+0x3f/0x50 __kasanslabfree+0x67/0x80 kfree+0x225/0x6c0 scsitargetdevrelease+0x3d/0x60 [scsimod] devicerelease+0xa3/0x220 kobjectcleanup+0x105/0x3a0 kobjectput+0x72/0xd0 putdevice+0x17/0x20 scsidevicedevrelease+0xacf/0x12c0 [scsimod] devicerelease+0xa3/0x220 kobjectcleanup+0x105/0x3a0 kobjectput+0x72/0xd0 putdevice+0x17/0x20 scsideviceput+0x7f/0xc0 [scsimod] sdevstoredelete+0xa5/0x120 [scsimod] devattrstore+0x43/0x80 sysfskfwrite+0xde/0x140 kernfsfopwriteiter+0x3ef/0x670 vfswrite+0x506/0x1470 ksys_write+0xfd/0x230 __x64syswrite+0x76/0xc0 x64syscall+0x213/0x1810(CVE-2026-23452)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix use-after-free in l2capunregisteruser

After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hcichandel"), l2capconndel() uses conn->lock to protect access to conn->users. However, l2capregisteruser() and l2capunregisteruser() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2capconndel().

This can lead to use-after-free and list corruption bugs, as reported by syzbot.

Fix this by changing l2capregisteruser() and l2capunregisteruser() to use conn->lock instead of hcidevlock(), ensuring consistent locking for the l2cap_conn structure.(CVE-2026-23461)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2026-23473)

In the Linux kernel, the following vulnerability has been resolved:

spi: fix statistics allocation

The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference.

Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).(CVE-2026-23475)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix krb5 mount with username option

Customer reported that some of their krb5 mounts were failing against a single server as the client was trying to mount the shares with wrong credentials. It turned out the client was reusing SMB session from first mount to try mounting the other shares, even though a different username= option had been specified to the other mounts.

By using username mount option along with sec=krb5 to search for principals from keytab is supported by cifs.upcall(8) since cifs-utils-4.8. So fix this by matching username mount option in match_session() even with Kerberos.

For example, the second mount below should fail with -ENOKEY as there is no 'foobar' principal in keytab (/etc/krb5.keytab). The client ends up reusing SMB session from first mount to perform the second one, which is wrong.

$ ktutil
ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts
Password for (CVE-2026-31392)

In the Linux kernel, the following vulnerability has been resolved:

mm/rmap: fix incorrect pte restoration for lazyfree folios

We batch unmap anonymous lazyfree folios by folio_unmap_pte_batch.  If the
batch has a mix of writable and non-writable bits, we may end up setting
the entire batch writable.  Fix this by respecting writable bit during
batching.

Although on a successful unmap of a lazyfree folio, the soft-dirty bit is
lost, preserve it on pte restoration by respecting the bit during
batching, to make the fix consistent w.r.t both writable bit and
soft-dirty bit.

I was able to write the below reproducer and crash the kernel. 
Explanation of reproducer (set 64K mTHP to always):

Fault in a 64K large folio.  Split the VMA at mid-point with
MADV_DONTFORK.  fork() - parent points to the folio with 8 writable ptes
and 8 non-writable ptes.  Merge the VMAs with MADV_DOFORK so that
folio_unmap_pte_batch() can determine all the 16 ptes as a batch.  Do
MADV_FREE on the range to mark the folio as lazyfree.  Write to the memory
to dirty the pte, eventually rmap will dirty the folio.  Then trigger
reclaim, we will hit the pte restoration path, and the kernel will crash
with the trace given below.

The BUG happens at:

    BUG_ON(atomic_inc_return(&ptc->anon_map_count) > 1 && rw);

The code path is asking for anonymous page to be mapped writable into the
pagetable.  The BUG_ON() firing implies that such a writable page has been
mapped into the pagetables of more than one process, which breaks
anonymous memory/CoW semantics.

[   21.134473] kernel BUG at mm/page_table_check.c:118!
[   21.134497] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
[   21.135917] Modules linked in:
[   21.136085] CPU: 1 UID: 0 PID: 1735 Comm: dup-lazyfree Not tainted 7.0.0-rc1-00116-g018018a17770 #1028 PREEMPT
[   21.136858] Hardware name: linux,dummy-virt (DT)
[   21.137019] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[   21.137308] pc : page_table_check_set+0x28c/0x2a8
[   21.137607] lr : page_table_check_set+0x134/0x2a8
[   21.137885] sp : ffff80008a3b3340
[   21.138124] x29: ffff80008a3b3340 x28: fffffdffc3d14400 x27: ffffd1a55e03d000
[   21.138623] x26: 0040000000000040 x25: ffffd1a55f7dd000 x24: 0000000000000001
[   21.139045] x23: 0000000000000001 x22: 0000000000000001 x21: ffffd1a55f217f30
[   21.139629] x20: 0000000000134521 x19: 0000000000134519 x18: 005c43e000040000
[   21.140027] x17: 0001400000000000 x16: 0001700000000000 x15: 000000000000ffff
[   21.140578] x14: 000000000000000c x13: 005c006000000000 x12: 0000000000000020
[   21.140828] x11: 0000000000000000 x10: 005c000000000000 x9 : ffffd1a55c079ee0
[   21.141077] x8 : 0000000000000001 x7 : 005c03e000040000 x6 : 000000004000ffff
[   21.141490] x5 : ffff00017fffce00 x4 : 0000000000000001 x3 : 0000000000000002
[   21.141741] x2 : 0000000000134510 x1 : 0000000000000000 x0 : ffff0000c08228c0
[   21.141991] Call trace:
[   21.142093]  page_table_check_set+0x28c/0x2a8 (P)
[   21.142265]  __page_table_check_ptes_set+0x144/0x1e8
[   21.142441]  __set_ptes_anysz.constprop.0+0x160/0x1a8
[   21.142766]  contpte_set_ptes+0xe8/0x140
[   21.142907]  try_to_unmap_one+0x10c4/0x10d0
[   21.143177]  rmap_walk_anon+0x100/0x250
[   21.143315]  try_to_unmap+0xa0/0xc8
[   21.143441]  shrink_folio_list+0x59c/0x18a8
[   21.143759]  shrink_lruvec+0x664/0xbf0
[   21.144043]  shrink_node+0x218/0x878
[   21.144285]  __node_reclaim.constprop.0+0x98/0x338
[   21.144763]  user_proactive_reclaim+0x2a4/0x340
[   21.145056]  reclaim_store+0x3c/0x60
[   21.145216]  dev_attr_store+0x20/0x40
[   21.145585]  sysfs_kf_write+0x84/0xa8
[   21.145835]  kernfs_fop_write_iter+0x130/0x1c8
[   21.145994]  vfs_write+0x2b8/0x368
[   21.146119]  ksys_write+0x70/0x110
[   21.146240]  __arm64_sys_write+0x24/0x38
[   21.146380]  invoke_syscall+0x50/0x120
[   21.146513]  el0_svc_common.constprop.0+0x48/0xf8
[   21.146679]  do_el0_svc+0x28/0x40
[   21.146798]  el0_svc+0x34/0x110
[   21.146926]  el0t
---truncated---(CVE-2026-31398)

In the Linux kernel, the following vulnerability has been resolved:

nvdimm/bus: Fix potential use after free in asynchronous initialization

Dingisoul with KASAN reports a use after free if device_add() fails in
nd_async_device_register().

Commit b6eae0f61db2 ("libnvdimm: Hold reference on parent while
scheduling async init") correctly added a reference on the parent device
to be held until asynchronous initialization was complete.  However, if
device_add() results in an allocation failure the ref count of the
device drops to 0 prior to the parent pointer being accessed.  Thus
resulting in use after free.

The bug bot AI correctly identified the fix.  Save a reference to the
parent pointer to be used to drop the parent reference regardless of the
outcome of device_add().(CVE-2026-31399)

In the Linux kernel, the following vulnerability has been resolved:

sunrpc: fix cache_request leak in cache_release

When a reader's file descriptor is closed while in the middle of reading
a cache_request (rp->offset != 0), cache_release() decrements the
request's readers count but never checks whether it should free the
request.

In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the
cache_request is removed from the queue and freed along with its buffer
and cache_head reference. cache_release() lacks this cleanup.

The only other path that frees requests with readers == 0 is
cache_dequeue(), but it runs only when CACHE_PENDING transitions from
set to clear. If that transition already happened while readers was
still non-zero, cache_dequeue() will have skipped the request, and no
subsequent call will clean it up.

Add the same cleanup logic from cache_read() to cache_release(): after
decrementing readers, check if it reached 0 with CACHE_PENDING clear,
and if so, dequeue and free the cache_request.(CVE-2026-31400)

In the Linux kernel, the following vulnerability has been resolved:

NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd

The /proc/fs/nfs/exports proc entry is created at module init
and persists for the module's lifetime. exports_proc_open()
captures the caller's current network namespace and stores
its svc_export_cache in seq->private, but takes no reference
on the namespace. If the namespace is subsequently torn down
(e.g. container destruction after the opener does setns() to a
different namespace), nfsd_net_exit() calls nfsd_export_shutdown()
which frees the cache. Subsequent reads on the still-open fd
dereference the freed cache_detail, walking a freed hash table.

Hold a reference on the struct net for the lifetime of the open
file descriptor. This prevents nfsd_net_exit() from running --
and thus prevents nfsd_export_shutdown() from freeing the cache
-- while any exports fd is open. cache_detail already stores
its net pointer (cd->net, set by cache_create_net()), so
exports_release() can retrieve it without additional per-file
storage.(CVE-2026-31403)

In the Linux kernel, the Bluetooth SCO module's sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: cls_fw: fix NULL pointer dereference on shared blocks

The old-method path in fw_classify() calls tcf_block_q() and
dereferences q->handle.  Shared blocks leave block->q NULL, causing a
NULL deref when an empty cls_fw filter is attached to a shared block
and a packet with a nonzero major skb mark is classified.

Reject the configuration in fw_change() when the old method (no
TCA_OPTIONS) is used on a shared block, since fw_classify()'s
old-method path needs block->q which is NULL for shared blocks.

The fixed null-ptr-deref calling stack:
 KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
 RIP: 0010:fw_classify (net/sched/cls_fw.c:81)
 Call Trace:
  tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)
  tc_run (net/core/dev.c:4401)
  __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)(CVE-2026-31421)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: cls_flow: fix NULL pointer dereference on shared blocks

flow_change() calls tcf_block_q() and dereferences q->handle to derive
a default baseclass.  Shared blocks leave block->q NULL, causing a NULL
deref when a flow filter without a fully qualified baseclass is created
on a shared block.

Check tcf_block_shared() before accessing block->q and return -EINVAL
for shared blocks.  This avoids the null-deref shown below:

=======================================================================
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:flow_change (net/sched/cls_flow.c:508)
Call Trace:
 tc_new_tfilter (net/sched/cls_api.c:2432)
 rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)
 [...]
=======================================================================(CVE-2026-31422)

In the Linux kernel, the following vulnerability has been resolved:

ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()

When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware
platforms, it has already started the EC and installed the address
space handler with the struct acpi_ec pointer as handler context.
However, acpi_ec_setup() propagates the error without any cleanup.

The caller acpi_ec_add() then frees the struct acpi_ec for non-boot
instances, leaving a dangling handler context in ACPICA.

Any subsequent AML evaluation that accesses an EC OpRegion field
dispatches into acpi_ec_space_handler() with the freed pointer,
causing a use-after-free:

 BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289)
 Write of size 8 at addr ffff88800721de38 by task init/1
 Call Trace:
  <TASK>
  mutex_lock (kernel/locking/mutex.c:289)
  acpi_ec_space_handler (drivers/acpi/ec.c:1362)
  acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293)
  acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246)
  acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509)
  acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700)
  acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327)
  acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392)
  </TASK>

 Allocated by task 1:
  acpi_ec_alloc (drivers/acpi/ec.c:1424)
  acpi_ec_add (drivers/acpi/ec.c:1692)

 Freed by task 1:
  kfree (mm/slub.c:6876)
  acpi_ec_add (drivers/acpi/ec.c:1751)

The bug triggers on reduced-hardware EC platforms (ec->gpe < 0)
when the GPIO IRQ provider defers probing. Once the stale handler
exists, any unprivileged sysfs read that causes AML to touch an
EC OpRegion (battery, thermal, backlight) exercises the dangling
pointer.

Fix this by calling ec_remove_handlers() in the error path of
acpi_ec_setup() before clearing first_ec. ec_remove_handlers()
checks each EC_FLAGS_* bit before acting, so it is safe to call
regardless of how far ec_install_handlers() progressed:

  -ENODEV  (handler not installed): only calls acpi_ec_stop()
  -EPROBE_DEFER (handler installed): removes handler, stops EC(CVE-2026-31426)

In the Linux kernel, the following vulnerability has been resolved:

net: skb: fix cross-cache free of KFENCE-allocated skb head

SKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2
value (e.g. 704 on x86_64) to avoid collisions with generic kmalloc
bucket sizes. This ensures that skb_kfree_head() can reliably use
skb_end_offset to distinguish skb heads allocated from
skb_small_head_cache vs. generic kmalloc caches.

However, when KFENCE is enabled, kfence_ksize() returns the exact
requested allocation size instead of the slab bucket size. If a caller
(e.g. bpf_test_init) allocates skb head data via kzalloc() and the
requested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then
slab_build_skb() -> ksize() returns that exact value. After subtracting
skb_shared_info overhead, skb_end_offset ends up matching
SKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free
the object to skb_small_head_cache instead of back to the original
kmalloc cache, resulting in a slab cross-cache free:

  kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected
  skbuff_small_head but got kmalloc-1k

Fix this by always calling kfree(head) in skb_kfree_head(). This keeps
the free path generic and avoids allocator-specific misclassification
for KFENCE objects.(CVE-2026-31429)

In the Linux kernel, the following vulnerability has been resolved:

X.509: Fix out-of-bounds access when parsing extensions

Leo reports an out-of-bounds access when parsing a certificate with
empty Basic Constraints or Key Usage extension because the first byte of
the extension is read before checking its length.  Fix it.

The bug can be triggered by an unprivileged user by submitting a
specially crafted certificate to the kernel through the keyrings(7) API.
Leo has demonstrated this with a proof-of-concept program responsibly
disclosed off-list.(CVE-2026-31430)

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Fix memory leak when a wq is reset

idxd_wq_disable_cleanup() which is called from the reset path for a
workqueue, sets the wq type to NONE, which for other parts of the
driver mean that the wq is empty (all its resources were released).

Only set the wq type to NONE after its resources are released.(CVE-2026-31441)

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Fix possible invalid memory access after FLR

In the case that the first Function Level Reset (FLR) concludes
correctly, but in the second FLR the scratch area for the saved
configuration cannot be allocated, it's possible for a invalid memory
access to happen.

Always set the deallocated scratch area to NULL after FLR completes.(CVE-2026-31442)

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix use-after-free in update_super_work when racing with umount

Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount
filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work
to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups
reads during unmount. However, this introduced a use-after-free because
update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which
accesses the kobject's kernfs_node after it has been freed by kobject_del()
in ext4_unregister_sysfs():

  update_super_work                ext4_put_super
  -----------------                --------------
                                   ext4_unregister_sysfs(sb)
                                     kobject_del(&sbi->s_kobj)
                                       __kobject_del()
                                         sysfs_remove_dir()
                                           kobj->sd = NULL
                                         sysfs_put(sd)
                                           kernfs_put()  // RCU free
  ext4_notify_error_sysfs(sbi)
    sysfs_notify(&sbi->s_kobj)
      kn = kobj->sd              // stale pointer
      kernfs_get(kn)             // UAF on freed kernfs_node
                                   ext4_journal_destroy()
                                     flush_work(&sbi->s_sb_upd_work)

Instead of reordering the teardown sequence, fix this by making
ext4_notify_error_sysfs() detect that sysfs has already been torn down
by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call
in that case. A dedicated mutex (s_error_notify_mutex) serializes
ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()
to prevent TOCTOU races where the kobject could be deleted between the
state_in_sysfs check and the sysfs_notify() call.(CVE-2026-31446)

In the Linux kernel, the following vulnerability has been resolved:

ext4: validate p_idx bounds in ext4_ext_correct_indexes

ext4_ext_correct_indexes() walks up the extent tree correcting
index entries when the first extent in a leaf is modified. Before
accessing path[k].p_idx->ei_block, there is no validation that
p_idx falls within the valid range of index entries for that
level.

If the on-disk extent header contains a corrupted or crafted
eh_entries value, p_idx can point past the end of the allocated
buffer, causing a slab-out-of-bounds read.

Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at
both access sites: before the while loop and inside it. Return
-EFSCORRUPTED if the index pointer is out of range, consistent
with how other bounds violations are handled in the ext4 extent
tree code.(CVE-2026-31449)

In the Linux kernel, the following vulnerability has been resolved:

ext4: publish jinode after initialization

ext4_inode_attach_jinode() publishes ei->jinode to concurrent users.
It used to set ei->jinode before jbd2_journal_init_jbd_inode(),
allowing a reader to observe a non-NULL jinode with i_vfs_inode
still unset.

The fast commit flush path can then pass this jinode to
jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and
may crash.

Below is the crash I observe:

BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fcfsyncbench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xasfindmarked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> filemapgetfolios_tag+0x87/0x2a0 __filemapfdatawaitrange+0x5f/0xd0 ? srsoaliasreturn_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? preemptcountsub+0x5f/0x80 ? srsoaliasreturnthunk+0x5/0xfbef5 ? capsafenice+0x37/0x70 ? srsoaliasreturnthunk+0x5/0xfbef5 ? preemptcountsub+0x5f/0x80 ? srsoaliasreturnthunk+0x5/0xfbef5 filemapfdatawaitrangekeeperrors+0x12/0x40 ext4fccommit+0x697/0x8b0 ? ext4filewriteiter+0x64b/0x950 ? srsoaliasreturnthunk+0x5/0xfbef5 ? preemptcountsub+0x5f/0x80 ? srsoaliasreturnthunk+0x5/0xfbef5 ? vfswrite+0x356/0x480 ? srsoaliasreturnthunk+0x5/0xfbef5 ? preemptcountsub+0x5f/0x80 ext4syncfile+0xf7/0x370 dofsync+0x3b/0x80 ? syscalltraceenter+0x108/0x1d0 __x64sysfdatasync+0x16/0x20 dosyscall64+0x62/0x2c0 entrySYSCALL64afterhwframe+0x76/0x7e ... ```

Fix this by initializing the jbd2inode first. Use smpwmb() and WRITEONCE() to publish ei->jinode after initialization. Readers use READONCE() to fetch the pointer.(CVE-2026-31450)

In the Linux kernel, the following vulnerability has been resolved:

ext4: replace BUGON with proper error handling in ext4readinlinefolio

Replace BUGON() with proper error handling when inline data size exceeds PAGESIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption.

The error is logged via ext4errorinode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.(CVE-2026-31451)

In the Linux kernel, the following vulnerability has been resolved:

ext4: convert inline data to extents when truncate exceeds inline size

Add a check in ext4_setattr() to convert files from inline data storage to extent-based storage when truncate() grows the file size beyond the inline capacity. This prevents the filesystem from entering an inconsistent state where the inline data flag is set but the file size exceeds what can be stored inline.

Without this fix, the following sequence causes a kernel BUG_ON():

1. Mount filesystem with inode that has inline flag set and small size
2. truncate(file, 50MB) - grows size but inline flag remains set
3. sendfile() attempts to write data
4. ext4writeinlinedata() hits BUGON(writesize > inlinecapacity)

The crash occurs because ext4writeinlinedata() expects inline storage to accommodate the write, but the actual inline capacity (~60 bytes for iblock + ~96 bytes for xattrs) is far smaller than the file size and write request.

The fix checks if the new size from setattr exceeds the inode's actual inline capacity (EXT4I(inode)->iinline_size) and converts the file to extent-based storage before proceeding with the size change.

This addresses the root cause by ensuring the inline data flag and file size remain consistent during truncate operations.(CVE-2026-31452)

In the Linux kernel, the following vulnerability has been resolved:

erofs: add GFP_NOIO in the bio completion if needed

The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vmmapram() with GFP_KERNEL.

Due to insufficient memory, vmmapram() may generate memory swapping I/O, which can cause submitbiowait to deadlock in some scenarios.

Trimmed down the call stack, as follows:

f2fssubmitreadio submitbio //biolist is initialized. mmcblkmqrecovery zerofsendio vmmapram __pteallockernel __allocpagesdirectreclaim shrinkfolio_list __swapwritepage submitbiowait //biolist is non-NULL, hang!!!

Use memallocnoio{save,restore}() to wrap up this path.(CVE-2026-31467)

In the Linux kernel, the following vulnerability has been resolved:

virtionet: Fix UAF on dstops when IFFXMITDSTRELEASE is cleared and napitx is false

A UAF issue occurs when the virtionet driver is configured with napitx=N and the device's IFFXMITDST_RELEASE flag is cleared (e.g., during the configuration of tc route filter rules).

When IFFXMITDSTRELEASE is removed from the netdevice, the network stack expects the driver to hold the reference to skb->dst until the packet is fully transmitted and freed. In virtionet with napitx=N, skbs may remain in the virtio transmit ring for an extended period.

If the network namespace is destroyed while these skbs are still pending, the corresponding dstops structure has freed. When a subsequent packet is transmitted, freeoldxmit() is triggered to clean up old skbs. It then calls dstrelease() on the skb associated with the stale dstentry. Since the dstops (referenced by the dst_entry) has already been freed, a UAF kernel paging request occurs.

fix it by adds skbdstdrop(skb) in startxmit to explicitly release the dst reference before the skb is queued in virtionet.

Call Trace: Unable to handle kernel paging request at virtual address ffff80007e150000 CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT ... percpucounteraddbatch+0x3c/0x158 lib/percpucounter.c:98 (P) dstrelease+0xe0/0x110 net/core/dst.c:177 skbreleaseheadstate+0xe8/0x108 net/core/skbuff.c:1177 skskbreasondrop+0x54/0x2d8 net/core/skbuff.c:1255 devkfreeskbanyreason+0x64/0x78 net/core/dev.c:3469 napiconsume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527 _freeoldxmit+0x164/0x230 drivers/net/virtionet.c:611 [virtionet] freeoldxmit drivers/net/virtionet.c:1081 [virtionet] startxmit+0x7c/0x530 drivers/net/virtionet.c:3329 [virtionet] ...

Reproduction Steps: NETDEV="enp3s0"

configqdiscroute_filter() { tc qdisc del dev $NETDEV root tc qdisc add dev $NETDEV root handle 1: prio tc filter add dev $NETDEV parent 1:0 \ protocol ip prio 100 route to 100 flowid 1:1 ip route add 192.168.1.100/32 dev $NETDEV realm 100 }

test_ns() { ip netns add testns ip link set $NETDEV netns testns ip netns exec testns ifconfig $NETDEV 10.0.32.46/24 ip netns exec testns ping -c 1 10.0.32.1 ip netns del testns }

configqdiscroute_filter

testns sleep 2 testns(CVE-2026-31469)

In the Linux kernel, the following vulnerability has been resolved:

spi: use generic driver_override infrastructure

When a driver is probed through __driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from _driverattach() without the device lock held is intentional. [1]

Also note that we do not enable the driveroverride feature of struct bustype, as SPI - in contrast to most other buses - passes "" to sysfsemit() when the driveroverride pointer is NULL. Thus, printing "\n" instead of "(null)\n".(CVE-2026-31487)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: use netlink policy range checks

Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors.

• CTAPROTOINFOTCPSTATE: reject values > TCPCONNTRACKSYNSENT2 at policy level, removing the manual >= TCPCONNTRACKMAX check.
• CTAPROTOINFOTCPWSCALEORIGINAL/REPLY: reject values > TCPMAXWSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count.
• CTAFILTERORIGFLAGS/REPLYFLAGS: use NLAPOLICYMASK with CTAFILTERF_ALL, removing the manual mask checks.
• CTAEXPECTFLAGS: use NLAPOLICYMASK with NFCTEXPECT_MASK, adding a new mask define grouping all valid expect flags.

Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.(CVE-2026-31495)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconntrackexpect: skip expectations in other netns via proc

Skip expectations that do not reside in this netns.

Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns's conntrack entries via proc").(CVE-2026-31496)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop

l2capconfigreq() processes CONFIGREQ for channels in BTCONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONFINPUTDONE and CONFOUTPUTDONE are already set from the initial configuration, the reconfiguration path falls through to l2capertminit(), which re-initializes txq, srejq, srejlist, and retranslist without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources.

Additionally, l2capparseconfreq() does not validate the minimum value of remotemps derived from the RFC maxpdusize option. A zero value propagates to l2capsegmentsdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory.

Fix the double-init by skipping l2capertminit() and l2capchanready() when the channel is already in BTCONNECTED state, while still allowing the reconfiguration parameters to be updated through l2capparseconfreq(). Also add a pdulen zero check in l2capsegment_sdu() as a safeguard.(CVE-2026-31498)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix deadlock in l2capconndel()

l2capconndel() calls canceldelayedworksync() for both infotimer and idaddrtimer while holding conn->lock. However, the work functions l2capinfotimeout() and l2capconnupdateidaddr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2capconndel() takes the lock.

Move the work cancellations before acquiring conn->lock and use disabledelayedworksync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hciconn_del().(CVE-2026-31499)

In the Linux kernel, the following vulnerability has been resolved:

iavf: fix out-of-bounds writes in iavfgetethtool_stats()

iavf incorrectly uses realnumtxqueues for ETHSSSTATS. Since the value could change in runtime, we should use numtx_queues instead.

Moreover iavfgetethtoolstats() uses numactivequeues while iavfgetssetcount() and iavfgetstatstrings() use realnumtxqueues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1].

For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3:

Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavfsetchannels() ... iavfallocqueues() -> numactivequeues = 8 iavfschedulefinishconfig() iavfgetssetcount() realnumtxqueues: 1 -> buffer for 1 queue iavfgetethtoolstats() numactivequeues: 8 -> out-of-bounds! iavffinishconfig() -> realnumtx_queues = 8

Use immutable numtxqueues in all related functions to avoid the issue.

[1] BUG: KASAN: vmalloc-out-of-bounds in iavfaddoneethtoolstat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800

CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x6f/0xb0 printreport+0x170/0x4f3 kasanreport+0xe1/0x180 iavfaddoneethtoolstat+0x200/0x270 iavfgetethtool_stats+0x14c/0x2e0 __devethtool+0x3d0c/0x5830 devethtool+0x12d/0x270 devioctl+0x53c/0xe30 sockdoioctl+0x1a9/0x270 sockioctl+0x3d4/0x5e0 __x64sysioctl+0x137/0x1c0 dosyscall64+0xf3/0x690 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... </TASK>

The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at _devethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8(CVE-2026-31505)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix null-ptr-deref on l2capsockready_cb

Before using sk pointer, check if it is null.

Fix the following:

KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm: kworker/0:5 Not tainted 7.0.0-rc4-00029-ga989fde763f4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-9.fc43 06/10/2025 Workqueue: events l2capinfotimeout RIP: 0010:kasanbyteaccessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce veth0_macvtap: entered promiscuous mode RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005582615a5008 CR3: 000000007007e000 CR4: 0000000000752ef0 PKRU: 55555554 Call Trace: <TASK> __kasancheckbyte+0x12/0x40 lockacquire+0x79/0x2e0 locksocknested+0x48/0x100 ? l2capsockreadycb+0x46/0x160 l2capsockreadycb+0x46/0x160 l2capconn_start+0x779/0xff0 ? __pfxl2capconnstart+0x10/0x10 ? l2capinfotimeout+0x60/0xa0 ? pfxmutexlock+0x10/0x10 l2capinfotimeout+0x68/0xa0 ? processscheduledworks+0xa8d/0x18c0 processscheduled_works+0xb6e/0x18c0 ? __pfxprocessscheduledworks+0x10/0x10 ? assignwork+0x3d5/0x5e0 worker_thread+0xa53/0xfc0 kthread+0x388/0x470 ? __pfxworkerthread+0x10/0x10 ? __pfxkthread+0x10/0x10 retfrom_fork+0x51e/0xb90 ? __pfxretfromfork+0x10/0x10 veth1macvtap: entered promiscuous mode ? __switch_to+0xc7d/0x1450 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- batmanadv: batadv0: Interface activated: batadvslave0 batmanadv: batadv0: Interface activated: batadvslave1 netdevsim netdevsim7 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim7 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 RIP: 0010:kasanbyteaccessible+0x12/0x30 Code: 79 ff ff ff 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 c1 ef 03 48 b8 00 00 00 00 00 fc ff df <0f> b6 04 07 3c 08 0f 92 c0 c3 cc cce ieee80211 phy39: Selected rate control algorithm 'minstrelht' RSP: 0018:ffffc90006e0f808 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffff89746018 RCX: 0000000080000001 RDX: 0000000000000000 RSI: ffffffff89746018 RDI: 000000000000004c RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffffff8aae3e70 R12: 0000000000000000 R13: 0000000000000260 R14: 0000000000000260 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880983c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e16139e9c CR3: 000000000e74e000 CR4: 0000000000752ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception(CVE-2026-31510)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Fix dangling pointer on mgmtaddadvpatternsmonitor_complete

This fixes the condition checking so mgmtpendingvalid is executed whenever status != -ECANCELED otherwise calling mgmtpendingfree(cmd) would kfree(cmd) without unlinking it from the list first, leaving a dangling pointer. Any subsequent list traversal (e.g., mgmtpendingforeach during __mgmtpoweroff, or another mgmtpendingvalid call) would dereference freed memory.(CVE-2026-31511)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2capecreddata_rcv()

l2capecreddatarcv() reads the SDU length field from skb->data using getunalignedle16() without first verifying that skb contains at least L2CAPSDULEN_SIZE (2) bytes. When skb->len is less than 2, this reads past the valid data in the skb.

The ERTM reassembly path correctly calls pskbmaypull() before reading the SDU length (l2capreassemblesdu, L2CAPSARSTART case). Apply the same validation to the Enhanced Credit Based Flow Control data path.(CVE-2026-31512)

In the Linux kernel, the following vulnerability has been resolved:

xfrm: prevent policy_hthresh.work from racing with netns teardown

A XFRMMSGNEWSPDINFO request can queue the per-net work item policy_hthresh.work onto the system workqueue.

The queued callback, xfrmhashrebuild(), retrieves the enclosing struct net via containerof(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrmhash_rebuild() may then dereference stale memory.

xfrmpolicyfini() already flushes policyhashwork during teardown, but it does not synchronize policy_hthresh.work.

Synchronize policyhthresh.work in xfrmpolicy_fini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.(CVE-2026-31516)

In the Linux kernel, the following vulnerability has been resolved:

esp: fix skb leak with espintcp and async crypto

When the TX queue for espintcp is full, espoutputtail_tcp will return an error and not free the skb, because with synchronous crypto, the common xfrm output code will drop the packet for us.

With async crypto (espoutputdone), we need to drop the skb when espoutputtail_tcp returns an error.(CVE-2026-31518)

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN

The BPF interpreter's signed 32-bit division and modulo handlers use the kernel abs() macro on s32 operands. The abs() macro documentation (include/linux/math.h) explicitly states the result is undefined when the input is the type minimum. When DST contains S32MIN (0x80000000), abs((s32)DST) triggers undefined behavior and returns S32MIN unchanged on arm64/x86. This value is then sign-extended to u64 as 0xFFFFFFFF80000000, causing do_div() to compute the wrong result.

The verifier's abstract interpretation (scalar32minmax_sdiv) computes the mathematically correct result for range tracking, creating a verifier/interpreter mismatch that can be exploited for out-of-bounds map value access.

Introduce abss32() which handles S32MIN correctly by casting to u32 before negating, avoiding signed overflow entirely. Replace all 8 abs((s32)...) call sites in the interpreter's sdiv32/smod32 handlers.

s32 is the only affected case -- the s64 division/modulo handlers do not use abs().(CVE-2026-31525)

In the Linux kernel, the following vulnerability has been resolved:

perf: Make sure to use pmu_ctx->pmu for groups

Oliver reported that x86pmudel() ended up doing an out-of-bound memory access when groupschedin() fails and needs to roll back.

This should be handled by the transaction callbacks, but he found that when the group leader is a software event, the transaction handlers of the wrong PMU are used. Despite the movegroup case in perfeventopen() and groupschedin() using pmuctx->pmu.

Turns out, inherit uses event->pmu to clone the events, effectively undoing the movegroup case for all inherited contexts. Fix this by also making inherit use pmuctx->pmu, ensuring all inherited counters end up in the same pmu context.

Similarly, _perfeventread() should use equally use pmuctx->pmu for the group case.(CVE-2026-31528)

In the Linux kernel, the following vulnerability has been resolved:

ipv4: nexthop: allocate skb dynamically in rtmgetnexthop()

When querying a nexthop object via RTMGETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSGGOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops.

This results in the following warning splat:

WARNING: net/ipv4/nexthop.c:3395 at rtmgetnexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtmgetnexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: <TASK> rtnetlinkrcvmsg (net/core/rtnetlink.c:6989) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) ___sys_sendmsg (net/socket.c:2641) __syssendmsg (net/socket.c:2671) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK>

Fix this by allocating the size dynamically using nhnlmsgsize() and using nlmsgnew(), this is consistent with nexthopnotify() behavior. In addition, adjust nhnlmsgsizegrp() so it calculates the size needed based on flags passed. While at it, also add the size of NHAFDB for nexthop group size calculation as it was missing too.

This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows:

addattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)

In the Linux kernel, the following vulnerability has been resolved:

can: raw: fix ro->uniq use-after-free in raw_rcv()

rawrelease() unregisters raw CAN receive filters via canrxunregister(), but receiver deletion is deferred with callrcu(). This leaves a window where rawrcv() may still be running in an RCU read-side critical section after rawrelease() frees ro->uniq, leading to a use-after-free of the percpu uniq storage.

Move freepercpu(ro->uniq) out of rawrelease() and into a raw-specific socket destructor. canrxunregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained.

mkl: applied manually

In the Linux kernel, the following vulnerability has been resolved:

net/tls: fix use-after-free in -EBUSY error path of tlsdoencryption

The -EBUSY handling in tlsdoencryption(), introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry.

When cryptoaeadencrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tlsencryptdone() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encryptpending. However, if tlsencryptasyncwait() returns an error, the synchronous error path in tlsdoencryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist.

The double-decrement corrupts the encryptpending sentinel (initialized to 1), making tlsencryptasyncwait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tlsrec via bpfexectxverdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record.

Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.(CVE-2026-31533)

In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gt: Check setdefaultsubmission() before deferencing

When the i915 driver firmware binaries are not present, the setdefaultsubmission pointer is not set. This pointer is dereferenced during suspend anyways.

Add a check to make sure it is set before dereferencing.

[ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes completed (elapsed 0.000 seconds) [ 23.309766] OOM killer disabled. [ 23.313027] Freezing remaining freezable tasks [ 23.318540] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 23.342038] serial 00:05: disabled [ 23.345719] serial 00:02: disabled [ 23.349342] serial 00:01: disabled [ 23.353782] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 23.358993] sd 1:0:0:0: [sdb] Synchronizing SCSI cache [ 23.361635] ata1.00: Entering standby power mode [ 23.368863] ata2.00: Entering standby power mode [ 23.445187] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 23.452194] #PF: supervisor instruction fetch in kernel mode [ 23.457896] #PF: errorcode(0x0010) - not-present page [ 23.463065] PGD 0 P4D 0 [ 23.465640] Oops: Oops: 0010 [#1] SMP NOPTI [ 23.469869] CPU: 8 UID: 0 PID: 211 Comm: kworker/u48:18 Tainted: G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 PREEMPT(voluntary) [ 23.482512] Tainted: [S]=CPUOUTOFSPEC, [W]=WARN [ 23.496511] Workqueue: async asyncrunentryfn [ 23.501087] RIP: 0010:0x0 [ 23.503755] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 23.510324] RSP: 0018:ffffb4a60065fca8 EFLAGS: 00010246 [ 23.515592] RAX: 0000000000000000 RBX: ffff9f428290e000 RCX: 000000000000000f [ 23.522765] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff9f428290e000 [ 23.529937] RBP: ffff9f4282907070 R08: ffff9f4281130428 R09: 00000000ffffffff [ 23.537111] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9f42829070f8 [ 23.544284] R13: ffff9f4282906028 R14: ffff9f4282900000 R15: ffff9f4282906b68 [ 23.551457] FS: 0000000000000000(0000) GS:ffff9f466b2cf000(0000) knlGS:0000000000000000 [ 23.559588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 23.565365] CR2: ffffffffffffffd6 CR3: 000000031c230001 CR4: 0000000000f70ef0 [ 23.572539] PKRU: 55555554 [ 23.575281] Call Trace: [ 23.577770] <TASK> [ 23.579905] intelenginesresetdefault_submission+0x42/0x60 [ 23.585695] __intelgtunsetwedged+0x191/0x200 [ 23.590360] intelgtunsetwedged+0x20/0x40 [ 23.594675] gtsanitize+0x15e/0x170 [ 23.598290] i915gemsuspendlate+0x6b/0x180 [ 23.602692] i915drmsuspend_late+0x35/0xf0 [ 23.607008] ? __pfxpcipmsuspendlate+0x10/0x10 [ 23.611843] dpmruncallback+0x78/0x1c0 [ 23.615817] devicesuspendlate+0xde/0x2e0 [ 23.620037] asyncsuspendlate+0x18/0x30 [ 23.624082] asyncrunentryfn+0x25/0xa0 [ 23.628129] processonework+0x15b/0x380 [ 23.632182] workerthread+0x2a5/0x3c0 [ 23.635973] ? __pfxworkerthread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [ 23.643464] ? __pfx_kthread+0x10/0x10 [ 23.647263] ? __pfxkthread+0x10/0x10 [ 23.651045] retfrom_fork+0x131/0x190 [ 23.654837] ? __pfxkthread+0x10/0x10 [ 23.658634] retfromforkasm+0x1a/0x30 [ 23.662597] </TASK> [ 23.664826] Modules linked in: [ 23.667914] CR2: 0000000000000000 [ 23.671271] ------------[ cut here ]------------

(cherry picked from commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad)(CVE-2026-31540)

In the Linux kernel, the following vulnerability has been resolved:

x86/platform/uv: Handle deconfigured sockets

When a socket is deconfigured, it's mapped to SOCK_EMPTY (0xffff). This causes a panic while allocating UV hub info structures.

Fix this by using NUMANONODE, allowing UV hub info structures to be allocated on valid nodes.(CVE-2026-31542)

In the Linux kernel, the following vulnerability has been resolved:

net: bonding: fix NULL deref in bonddebugrlbhashshow

rlbclearslave intentionally keeps RLB hash-table entries on the rxhashtblusedhead list with slave set to NULL when no replacement slave is available. However, bonddebugrlbhashshow visites clientinfo->slave without checking if it's NULL.

Other used-list iterators in bond_alb.c already handle this NULL-slave state safely:

• rlbupdateclient returns early on !client_info->slave
• rlbrequpdateslaveclients, rlbclearslave, and rlb_rebalance compare slave values before visiting
• lbrequpdatesubnetclients continues if slave is NULL

The following NULL deref crash can be trigger in bonddebugrlbhashshow:

[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bonddebugrlbhashshow (drivers/net/bonding/bonddebugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seqreaditer (fs/seqfile.c:231) [ 1.296341] seqread (fs/seqfile.c:164) [ 1.296493] fullproxyread (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfsread (fs/readwrite.c:572) [ 1.296981] ksysread (fs/readwrite.c:717) [ 1.297132] dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) [ 1.297325] entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

Add a NULL check and print "(none)" for entries with no assigned slave.(CVE-2026-31546)

In the Linux kernel, the following vulnerability has been resolved:

futex: Clear stale exiting pointer in futexlockpi() retry path

Fuzzying/stressing futexes triggered:

WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524

When futexlockpi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'.

After waitforownerexiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futexlockpiatomic() returns a different error, the bogus pointer is passed to waitforowner_exiting().

CPU0 CPU1 CPU2 futexlockpi(uaddr) // acquires the PI futex exit() futexcleanupbegin() futexstate = EXITING; futexlockpi(uaddr) futexlockpiatomic() attachtopiowner() // observes EXITING *exiting = owner; // takes ref return -EBUSY waitforownerexiting(-EBUSY, owner) puttaskstruct(); // drops ref // exiting still points to owner goto retry; futexlockpiatomic() lockpiupdateatomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; waitforownerexiting(-EAGAIN, exiting) // stale WARNON_ONCE(exiting)

Fix this by resetting upon retry, essentially aligning it with requeue_pi.(CVE-2026-31555)

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix fence put before wait in amdgpuamdkfdsubmit_ib

amdgpuamdkfdsubmitib() submits a GPU job and gets a fence from amdgpuib_schedule(). This fence is used to wait for job completion.

Currently, the code drops the fence reference using dmafenceput() before calling dmafencewait().

If dmafenceput() releases the last reference, the fence may be freed before dmafencewait() is called. This can lead to a use-after-free.

Fix this by waiting on the fence first and releasing the reference only after dmafencewait() completes.

Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpuamdkfd.c:697 amdgpuamdkfdsubmitib() warn: passing freed memory 'f' (line 696)

(cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)(CVE-2026-31566)

In the Linux kernel, the following vulnerability has been resolved:

can: gw: fix OOB heap access in cgwcsumcrc8_rel()

cgwcsumcrc8rel() correctly computes bounds-safe indices via calcidx():

int from = calc_idx(crc8->from_idx, cf->len);
int to   = calc_idx(crc8->to_idx,   cf->len);
int res  = calc_idx(crc8->result_idx, cf->len);

if (from < 0 || to < 0 || res < 0)
    return;

However, the loop and the result write then use the raw s8 fields directly instead of the computed variables:

for (i = crc8->from_idx; ...)        /* BUG: raw negative index */
cf->data[crc8->result_idx] = ...;    /* BUG: raw negative index */

With fromidx = toidx = resultidx = -64 on a 64-byte CAN FD frame, calcidx(-64, 64) = 0 so the guard passes, but the loop iterates with i = -64, reading cf->data[-64], and the write goes to cf->data[-64]. This write might end up to 56 (7.0-rc) or 40 (<= 6.19) bytes before the start of the canfd_frame on the heap.

The companion function cgwcsumxorrel() uses from/to/res correctly throughout; fix cgwcsumcrc8rel() to match.

Confirmed with KASAN on linux-7.0-rc2: BUG: KASAN: slab-out-of-bounds in cgwcsumcrc8rel+0x515/0x5b0 Read of size 1 at addr ffff8880076619c8 by task poccgw_oob/62

To configure the can-gw crc8 checksums CAPNETADMIN is needed.(CVE-2026-31570)

In the Linux kernel, the following vulnerability has been resolved:

KVM: SEV: Drop WARN on large size for KVMMEMORYENCRYPTREGREGION

Drop the WARN in sevpinmemory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing:

struct kvmencregion range = { .addr = 0, .size = -1ul, };

_vmioctl(vm, KVMMEMORYENCRYPTREGREGION, &range);

Note, the checks in sevmemencregisterregion() that presumably exist to verify the incoming address+size are completely worthless, as both "addr" and "size" are u64s and SEV is 64-bit only, i.e. they can't be greater than ULONG_MAX. That wart will be cleaned up in the near future.

if (range->addr > ULONG_MAX || range->size > ULONG_MAX)
    return -EINVAL;

Opportunistically add a comment to explain why the code calculates the number of pages the "hard" way, e.g. instead of just shifting @ulen.(CVE-2026-31590)

In the Linux kernel, the following vulnerability has been resolved:

PCI: endpoint: pci-epf-vntb: Stop cmdhandler work in epfntbepccleanup

Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down.

Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epfntbcmdhandler+0x54/0x200 [pciepfvntb] (P) processonework+0x154/0x3b0 workerthread+0x2c8/0x400 kthread+0x148/0x210 retfromfork+0x10/0x20(CVE-2026-31595)

In the Linux kernel, the following vulnerability has been resolved:

x86/CPU: Fix FPDSS on Zen1

Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread.

Fix that with a chicken bit.(CVE-2026-31628)

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: proc: size address buffers for %pISpc output

The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc".

That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6addris_isatap().

As a result, a case such as

is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c.

Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf().

Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example(CVE-2026-31630)

In the Linux kernel, the following vulnerability has been resolved:

mmc: vub300: fix NULL-deref on disconnect

Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.(CVE-2026-31651)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_ct: fix use-after-free in timeout object destroy

nftcttimeoutobjdestroy() frees the timeout object with kfree() immediately after nfctuntimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcudereference() in nfcttimeoutdata().

Add an rcuhead to struct nfcttimeout and use kfreercu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c.

KASAN report: BUG: KASAN: slab-use-after-free in nfconntracktcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80

Call Trace: nfconntracktcppacket+0x1381/0x29d0 nfconntrackin+0x612/0x8b0 nfhook_slow+0x70/0x100 __iplocalout+0x1b2/0x210 tcpsendmsglocked+0x722/0x1580 _syssendto+0x2d8/0x320

Allocated by task 75: nftcttimeoutobjinit+0xf6/0x290 nftobjinit+0x107/0x1b0 nftablesnewobj+0x680/0x9c0 nfnetlinkrcvbatch+0xc29/0xe00

Freed by task 26: nftobjdestroy+0x3f/0xa0 nftablestransdestroywork+0x51c/0x5c0 processonework+0x2c4/0x5a0(CVE-2026-31665)

In the Linux kernel, the following vulnerability has been resolved:

Input: uinput - fix circular locking dependency with ff-core

A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller):

ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex

The cycle is caused by four lock acquisition paths:

1. ff upload: inputffupload() holds ff->mutex and calls uinputdevuploadeffect() -> uinputrequestsubmit() -> uinputrequest_send(), which acquires udev->mutex.

2. device create: uinputioctlhandler() holds udev->mutex and calls uinputcreatedevice() -> inputregisterdevice(), which acquires input_mutex.

3. device register: inputregisterdevice() holds inputmutex and calls kbdconnect() -> inputregisterhandle(), which acquires dev->mutex.

4. evdev release: evdevrelease() calls inputflushdevice() under dev->mutex, which calls inputff_flush() acquiring ff->mutex.

Fix this by introducing a new statelock spinlock to protect udev->state and udev->dev access in uinputrequestsend() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinputdevevent() -- both operations are safe under a spinlock (ktimegetts64() and wakeup_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes.

To keep state transitions visible to uinputrequestsend(), protect writes to udev->state in uinputcreatedevice() and uinputdestroydevice() with the same state_lock spinlock.

Additionally, move initcompletion(&request->done) from uinputrequestsend() to uinputrequestsubmit() before uinputrequestreserveslot(). Once the slot is allocated, uinputflushrequests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible.

Lock ordering after the fix:

ff->mutex -> statelock (spinlock, leaf) udev->mutex -> statelock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)(CVE-2026-31667)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: sch_netem: fix out-of-bounds access in packet corruption

In netemenqueue(), the packet corruption logic uses getrandomu32below(skbheadlen(skb)) to select an index for modifying skb->data. When an AFPACKET TXRING sends fully non-linear packets over an IPIP tunnel, skbheadlen(skb) evaluates to 0.

Passing 0 to getrandomu32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access.

Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic.(CVE-2026-31675)

In the Linux kernel, the following vulnerability has been resolved:

crypto: af_alg - limit RX SG extraction by receive buffer budget

Make afalgget_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget.

afalggetrsgl() currently uses afalgreadable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining afalg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request.

If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.(CVE-2026-31677)

In the Linux kernel, the following vulnerability has been resolved:

openvswitch: defer tunnel netdev_put to RCU release

ovsnetdevtunneldestroy() may run after NETDEVUNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev.

Do not release vport->dev in ovsnetdevtunneldestroy(). Instead, let vportnetdev_free() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL.(CVE-2026-31678)

In the Linux kernel, a memory out-of-bounds access vulnerability exists in the actcsum module's tcfcsumact() function when processing nested VLAN headers. When an skb still carries in-payload VLAN tags, the function walks nested VLAN headers directly from skb->data. The current code reads vlan->hvlanencapsulatedproto and then pulls VLANHLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing hvlanencapsulatedproto reads past the linear area, and the following skbpull(VLANHLEN) may violate skb invariants.(CVE-2026-31684)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ip6t_eui64: reject invalid MAC header for all packets

eui64_mt6() derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address.

The existing guard only rejects an invalid MAC header when par->fragoff != 0. For packets with par->fragoff == 0, eui64_mt6() can still reach eth_hdr(skb) even when the MAC header is not valid.

Fix this by removing the par->fragoff != 0 condition so that packets with an invalid MAC header are rejected before accessing eth_hdr(skb).(CVE-2026-31685)

In the Linux kernel, the following vulnerability has been resolved:

EDAC/mc: Fix error path ordering in edacmcalloc()

When the mci->pvtinfo allocation in edacmcalloc() fails, the error path will call putdevice() which will end up calling the device's release function.

However, the init ordering is wrong such that device_initialize() happens after the failed allocation and thus the device itself and the release function pointer are not initialized yet when they're called:

MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobjectput() is being called. WARNING: lib/kobject.c:734 at kobjectput, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobjectput Call Trace: <TASK> edacmcalloc+0xbe/0xe0 [edaccore] amd64edacinit+0x7a4/0xff0 [amd64_edac] ? __pfxamd64edacinit+0x10/0x10 [amd64edac] dooneinitcall ...

Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used.

This was found by Claude while reviewing another EDAC patch.(CVE-2026-31689)

In the Linux kernel, the following vulnerability has been resolved:

crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed

When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrumentcopytouser ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in inlinecopytouser ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in copytouser+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388

CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dumpstacklvl+0xc5/0x110 ../lib/dumpstack.c:120 printaddressdescription ../mm/kasan/report.c:378 [inline] printreport+0xbc/0x260 ../mm/kasan/report.c:482 kasanreport+0xa2/0xe0 ../mm/kasan/report.c:595 checkregioninline ../mm/kasan/generic.c:-1 [inline] kasancheckrange+0x264/0x2c0 ../mm/kasan/generic.c:200 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] inlinecopytouser ../include/linux/uaccess.h:205 [inline] copytouser+0x66/0xa0 ../lib/usercopy.c:26 copytouser ../include/linux/uaccess.h:236 [inline] sevioctldogetid2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sevioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfsioctl ../fs/ioctl.c:51 [inline] __dosysioctl ../fs/ioctl.c:597 [inline] __sesysioctl+0x11d/0x1b0 ../fs/ioctl.c:583 dosyscallx64 ../arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe0/0x800 ../arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as _sevdocmdlocked() is expected to return -EIO on any firwmware error.(CVE-2026-31697)

In the Linux kernel, the following vulnerability has been resolved:

crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed

When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrumentcopytouser ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in inlinecopytouser ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in copytouser+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033

CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 34.84.12-0 11/17/2025 Call Trace: <TASK> dumpstacklvl+0xc5/0x110 ../lib/dumpstack.c:120 printaddressdescription ../mm/kasan/report.c:378 [inline] printreport+0xbc/0x260 ../mm/kasan/report.c:482 kasanreport+0xa2/0xe0 ../mm/kasan/report.c:595 checkregioninline ../mm/kasan/generic.c:-1 [inline] kasancheckrange+0x264/0x2c0 ../mm/kasan/generic.c:200 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] inlinecopytouser ../include/linux/uaccess.h:205 [inline] copytouser+0x66/0xa0 ../lib/usercopy.c:26 copytouser ../include/linux/uaccess.h:236 [inline] sevioctldopdhexport+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sevioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfsioctl ../fs/ioctl.c:51 [inline] __dosysioctl ../fs/ioctl.c:597 [inline] __sesysioctl+0x11d/0x1b0 ../fs/ioctl.c:583 dosyscallx64 ../arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe0/0x800 ../arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as _sevdocmdlocked() is expected to return -EIO on any firwmware error.(CVE-2026-31698)

In the Linux kernel, the following vulnerability has been resolved:

crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed

When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes firmware requires will overflow the kernel-allocated buffer and leak data to userspace.

BUG: KASAN: slab-out-of-bounds in instrumentcopytouser ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in inlinecopytouser ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in copytouser+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405

CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dumpstacklvl+0xc5/0x110 ../lib/dumpstack.c:120 printaddressdescription ../mm/kasan/report.c:378 [inline] printreport+0xbc/0x260 ../mm/kasan/report.c:482 kasanreport+0xa2/0xe0 ../mm/kasan/report.c:595 checkregioninline ../mm/kasan/generic.c:-1 [inline] kasancheckrange+0x264/0x2c0 ../mm/kasan/generic.c:200 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] inlinecopytouser ../include/linux/uaccess.h:205 [inline] copytouser+0x66/0xa0 ../lib/usercopy.c:26 copytouser ../include/linux/uaccess.h:236 [inline] sevioctldopekcsr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sevioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfsioctl ../fs/ioctl.c:51 [inline] __dosysioctl ../fs/ioctl.c:597 [inline] __sesysioctl+0x11d/0x1b0 ../fs/ioctl.c:583 dosyscallx64 ../arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe0/0x800 ../arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as _sevdocmdlocked() is expected to return -EIO on any firwmware error.(CVE-2026-31699)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix OOB read in smb2ioctlqueryinfo QUERYINFO path

smb2ioctlqueryinfo() has two response-copy branches: PASSTHRUFSCTL and the default QUERYINFO path. The QUERYINFO branch clamps qi.inputbufferlength to the server-reported OutputBufferLength and then copies qi.inputbufferlength bytes from qirsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rspiov[1].iov_len.

A malicious server can return OutputBufferLength larger than the actual QUERYINFO response, causing copyto_user() to walk past the response buffer and expose adjacent kernel heap to userspace.

Guard the QUERYINFO copy with a bounds check on the actual Buffer payload. Use structsize(qirsp, Buffer, qi.inputbuffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.(CVE-2026-31708)

In the Linux kernel, the following vulnerability has been resolved:

vxlan: validate ND option lengths in vxlannacreate

vxlannacreate() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.(CVE-2026-31738)

In the Linux kernel, the following vulnerability has been resolved:

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.(CVE-2026-31752)

In the Linux kernel, the following vulnerability has been resolved:

usb: cdns3: gadget: fix NULL pointer dereference in ep_queue

When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when _cdns3gadgetepqueue() is called, causing a kernel crash.

Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints.

This prevents potential crashes when ep_queue is called on endpoints that are not ready.(CVE-2026-31755)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_event: move wake reason storage into validated event handlers

hcistorewakereason() is called from hcieventpacket() immediately after stripping the HCI event header but before hcieventfunc() enforces the per-event minimum payload length from hciev_table. This means a short HCI event frame can reach bacpy() before any bounds check runs.

Rather than duplicating skb parsing and per-event length checks inside hcistorewakereason(), move wake-address storage into the individual event handlers after their existing event-length validation has succeeded. Convert hcistorewakereason() into a small helper that only stores an already-validated bdaddr while the caller holds hcidevlock(). Use the same helper after hcieventfunc() with a NULL address to preserve the existing unexpected-wake fallback semantics when no validated event handler records a wake address.

Annotate the helper with _musthold(&hdev->lock) and add lockdepassertheld(&hdev->lock) so future call paths keep the lock contract explicit.

Call the helper from hciconnrequestevt(), hciconncompleteevt(), hcisyncconncompleteevt(), leconncompleteevt(), hcileadvreportevt(), hcileextadvreportevt(), hciledirectadvreportevt(), hcilepasyncestablishedevt(), and hcilepastreceivedevt().(CVE-2026-31771)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: SMP: derive legacy responder STK authentication from MITM state

The legacy responder path in smprandom() currently labels the stored STK as authenticated whenever pendingseclevel is BTSECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved.

For Just Works/Confirm legacy pairing, SMPFLAGMITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result.

This also keeps the legacy path aligned with the Secure Connections code, which already treats JUSTWORKS/JUSTCFM as unauthenticated.(CVE-2026-31773)

In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwlmvmndmatchinfo_handler()

The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-31779)

In the Linux kernel, the following vulnerability has been resolved:

drm/ioc32: stop speculation on the drmcompatioctl path

The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling arrayindexnospec() on the index to the function pointer list.(CVE-2026-31781)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: validate LTK enc_size on load

Load Long Term Keys stores the user-provided encsize and later uses it to size fixed-size stack operations when replying to LE LTK requests. An encsize larger than the 16-byte key buffer can therefore overflow the reply stack buffer.

Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.(CVE-2026-43020)

In the Linux kernel, the following vulnerability has been resolved:

net: use skbheaderpointer() for TCPv4 GSO frag_off check

Syzbot reported a KMSAN uninit-value warning in gsofeaturescheck() called from netifskbfeatures() [1].

gsofeaturescheck() reads iph->fragoff to decide whether to clear mangleidfeatures. Accessing the IPv4 header via iphdr()/inneriphdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PFPACKET paths.

Use skbheaderpointer() for the TCPv4 frag_off check so the header read is robust whether data is already linear or needs copying.

[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407(CVE-2026-43036)

In the Linux kernel, the following vulnerability has been resolved:

net: ipv6: ndisc: fix ndiscrauseropt to initialize nduseropt_padX fields to zero to prevent an info-leak

When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data

The fix is simple, just zeroes the padding fields.(CVE-2026-43040)

In the Linux kernel, the following vulnerability has been resolved:

crypto: af-alg - fix NULL pointer dereference in scatterwalk

The AFALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new afalgtsgl structure. If a sendmsg() fills an SGL exactly to MAXSGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry.

This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference.

Fix this by explicitly unmarking the end of the previous SGL when performing sgchain() in afalgalloctsgl().(CVE-2026-43043)

In the Linux kernel, the following vulnerability has been resolved:

serial: 8250: Fix TX deadlock when using DMA

dmaengine_terminate_async does not guarantee that the __dma_tx_complete callback will run. The callback is currently the only place where dma->tx_running gets cleared. If the transaction is canceled and the callback never runs, then dma->tx_running will never get cleared and we will never schedule new TX DMA transactions again.

This change makes it so we clear dma->tx_running after we terminate the DMA transaction. This is "safe" because serial8250_tx_dma_flush is holding the UART port lock. The first thing the callback does is also grab the UART port lock, so access to dma->tx_running is serialized.(CVE-2026-43061)

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Fix not releasing workqueue on .release()

The workqueue associated with an DSA/IAA device is not released when the object is freed.(CVE-2026-43064)

In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel/uncore: Skip discovery table for offline dies

This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0.

WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncorepcipmuregister+0x136/0x160 [inteluncore]

Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncorepcipmu_register(), which may trigger the warning above or cause other issues.(CVE-2026-43079)

In the Linux kernel, the following vulnerability has been resolved:

ipv4: icmp: fix null-ptr-deref in icmpbuildprobe()

ipv6stub->ipv6devfind() may return ERRPTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIGIPV6=m and not loaded), and passing this error pointer to devhold() will cause a kernel crash with null-ptr-deref.

Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface".(CVE-2026-43099)

In the Linux kernel, the following vulnerability has been resolved:

powerpc/smp: Add check for kcalloc() failure in parsethreadgroups()

As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing it to ofpropertyreadu32array().(CVE-2026-43148)

In the Linux kernel, the following vulnerability has been resolved:

net: usb: pegasus: enable basic endpoint checking

pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors:

• usb_rcvbulkpipe(dev, 1) for RX data
• usb_sndbulkpipe(dev, 2) for TX data
• usb_rcvintpipe(dev, 3) for status interrupts

A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes.

Add a pegasususbep enum for endpoint numbers, replacing magic constants throughout. Add usbcheckbulkendpoints() and usbcheckintendpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion.

Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")(CVE-2026-43156)

In the Linux kernel, the following vulnerability has been resolved:

md/bitmap: fix GPF in write_page caused by resize race

A General Protection Fault occurs in writepage() during array resize: RIP: 0010:writepage+0x22b/0x3c0 [md_mod]

This is a use-after-free race between bitmapdaemonwork() and __bitmapresize(). The daemon iterates over bitmap->storage.filemap without locking, while the resize path frees that storage via mdbitmapfileunmap(). quiesce() does not stop the md thread, allowing concurrent access to freed pages.

Fix by holding mddev->bitmap_info.mutex during the bitmap update.(CVE-2026-43163)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: ioam: fix heap buffer overflow in _ioam6filltracedata()

On the receive path, _ioam6filltracedata() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skbsharedinfo), which corrupts adjacent heap memory and leads to a kernel panic.

Add a shared helper ioam6tracecompute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it:

• in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation;
• in exthdrs.c (receive path, ipv6hopioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written.

Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6MASKSHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).(CVE-2026-43186)

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Make cpumaskofnode() robust against NUMANONODE

The arch definition of cpumaskofnode() cannot handle NUMANONODE - which is a valid index - so add a check for this.(CVE-2026-43212)

In the Linux kernel, the following vulnerability has been resolved:

x86/kexec: add a sanity check on previous kernel's ima kexec buffer

When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.

BUG: unable to handle page fault for address: ffff97793ff47000
RIP: ima_restore_measurement_list+0xdc/0x45a
#PF: error_code(0x0000) – not-present page

Other architectures already validate the range with pageisram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.

Without carrying the measurement list across kexec, the attestation would fail.(CVE-2026-43240)

In the Linux kernel, the following vulnerability has been resolved:

gfs2: fiemap page fault fix

In gfs2fiemap(), we are calling iomapfiemap() while holding the inode glock. This can lead to recursive glock taking if the fiemap buffer is memory mapped to the same inode and accessing it triggers a page fault.

Fix by disabling page faults for iomap_fiemap() and faulting in the buffer by hand if necessary.

Fixes xfstest generic/742.(CVE-2026-43262)

In the Linux kernel, the following vulnerability has been resolved:

ceph: supply snapshot context in cephzeropartial_object()

The cephzeropartial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots.

Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph (CVE-2026-43273)

In the Linux kernel, the following vulnerability has been resolved:

ext4: move ext4percpuparaminit() before ext4mb_init()

When running kvm-xfstests -c ext4/1k -C 1 generic/383 with the DOUBLE_CHECK macro defined, the following panic is triggered:

================================================================== EXT4-fs error (device vdc): ext4validateblockbitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpucounteraddbatch+0x13/0xa0 Call Trace: <TASK> ext4markgroupbitmapcorrupted+0xcb/0xe0 ext4validateblockbitmap+0x2a1/0x2f0 ext4readblockbitmap+0x33/0x50 mbgroupbbbitmapalloc+0x33/0x80 ext4mbaddgroupinfo+0x190/0x250 ext4mbinitbackend+0x87/0x290 ext4mbinit+0x456/0x640 __ext4fillsuper+0x1072/0x1680 ext4_fillsuper+0xd3/0x280 gettreebdevflags+0x132/0x1d0 vfsgettree+0x29/0xd0 vfscmdcreate+0x59/0xe0 __dosysfsconfig+0x4f6/0x6b0 dosyscall64+0x50/0x1f0

entrySYSCALL64afterhwframe+0x76/0x7e

This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test

With DOUBLECHECK defined, mbgroupbbbitmapalloc() reads and validates the block bitmap. When the validation fails, ext4markgroupbitmapcorrupted() attempts to update sbi->sfreeclusterscounter. However, this percpucounter has not been initialized yet at this point, which leads to the panic described above.

Fix this by moving the execution of ext4percpuparaminit() to occur before ext4mb_init(), ensuring the per-CPU counters are initialized before they are used.(CVE-2026-43288)

In the Linux kernel, the following vulnerability has been resolved:

mm/vmalloc: prevent RCU stalls in kasanreleasevmalloc_node

When CONFIGPAGEOWNER is enabled, freeing KASAN shadow pages during vmalloc cleanup triggers expensive stack unwinding that acquires RCU read locks. Processing a large purge_list without rescheduling can cause the task to hold CPU for extended periods (10+ seconds), leading to RCU stalls and potential OOM conditions.

The issue manifests in purgevmapnode() -> kasanreleasevmallocnode() where iterating through hundreds or thousands of vmaparea entries and freeing their associated shadow pages causes:

rcu: INFO: rcupreempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcunode (CPUs 0-1): P6229/1:b..l ... task:kworker/0:17 state:R running task stack:28840 pid:6229 ... kasanreleasevmallocnode+0x1ba/0xad0 mm/vmalloc.c:2299 purgevmap_node+0x1ba/0xad0 mm/vmalloc.c:2299

Each call to kasanreleasevmalloc() can free many pages, and with pageowner tracking, each free triggers savestack() which performs stack unwinding under RCU read lock. Without yielding, this creates an unbounded RCU critical section.

Add periodic cond_resched() calls within the loop to allow: - RCU grace periods to complete - Other tasks to run - Scheduler to preempt when needed

The fix uses need_resched() for immediate response under load, with a batch count of 32 as a guaranteed upper bound to prevent worst-case stalls even under light load.(CVE-2026-43292)

In the Linux kernel, the following vulnerability has been resolved:

net: ipa: fix event ring index not programmed for IPA v5.0+

For IPA v5.0+, the event ring index field moved from CHCCNTXT0 to CHCCNTXT1. The v5.0 register definition intended to define this field in the CHCCNTXT1 fmask array but used the old identifier of ERINDEX instead of CHERINDEX.

Without a valid event ring, GSI channels could never signal transfer completions. This caused gsichanneltransquiesce() to block forever in waitfor_completion().

At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.(CVE-2026-43345)

In the Linux kernel, the following vulnerability has been resolved:

io_uring/kbuf: check if target buffer list is still legacy on recycle

There's a gap between when the buffer was grabbed and when it potentially gets recycled, where if the list is empty, someone could've upgraded it to a ring provided type. This can happen if the request is forced via io-wq. The legacy recycling is missing checking if the buffer_list still exists, and if it's of the correct type. Add those checks.(CVE-2026-43366)

In the Linux kernel, the following vulnerability has been resolved:

libceph: prevent potential out-of-bounds reads in processmessageheader()

If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in processmessageheader().

Perform an explicit bounds check before decoding the message header.(CVE-2026-43406)

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix memory leaks in cephmdscbuild_path()

Add __putname() calls to error code paths that did not free the "path" pointer obtained by _getname(). If ownership of this pointer is not passed to the caller via pathinfo.path, the function must free it before returning.(CVE-2026-43419)

In the Linux kernel, the following vulnerability has been resolved:

usb: class: cdc-wdm: fix reordering issue in read code path

Quoting the bug report:

Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdmread() can see the new length and call copyto_user() on uninitialized memory. This also violates LKMM data race rules [1].

Fix it by using WRITE_ONCE and memory barriers.(CVE-2026-43427)

In the Linux kernel, the following vulnerability has been resolved:

USB: core: Limit the length of unkillable synchronous timeouts

The usbcontrolmsg(), usbbulkmsg(), and usbinterruptmsg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.

To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector.

In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.(CVE-2026-43428)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix deadlock between devlink lock and esw->wq

esw->workqueue executes eswfunctionschangedeventhandler -> eswvfschangedevent_handler and acquires the devlink lock.

.eswitchmodeset (acquires devlink lock in devlinknlpredoit) -> mlx5devlinkeswitchmodeset -> mlx5eswitchdisablelocked -> mlx5eswitcheventhandlerunregister -> flushworkqueue deadlocks when eswvfschangedevent_handler executes.

Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5eswitcheventhandlerunregister. - the counter is read and passed to the ephemeral mlx5hostwork struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5eswitchcleanup does the final draining before destroying the wq.

No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vportchangehandler work items, but that's ok since those are disabled elsewhere: - mlx5eswitchdisablelocked disables the vport eq notifier. - mlx5eswvportdisable disarms the HW EQ notification and marks vport->enabled under statelock to false to prevent pending vport handler from doing anything. - mlx5eswitch_cleanup destroys the workqueue and makes sure all events are disabled/finished.(CVE-2026-43468)

In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAYBACKLOG requests MAYBACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications. The Linux kernel CVE team has assigned CVE-2026-43493 to this issue.(CVE-2026-43493)

In the Linux kernel, the following vulnerability has been resolved:

net: skbuff: propagate shared-frag marker through frag-transfer helpers

Two frag-transfer helpers (__pskbcopyfclone() and skbshift()) fail to propagate the SKBFLSHAREDFRAG bit in skbshinfo()->flags when moving frags from source to destination. pskbcopyfclone() defers the rest of the shinfo metadata to skbcopyheader() after copying frag descriptors, but that helper only carries over gso{size,segs, type} and never touches skbshinfo()->flags; skbshift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skbhassharedfrag() as false.

The mismatch is harmful in any in-place writer that uses skbhassharedfrag() to decide whether shared pages must be detoured through skbcowdata(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nfdupipv4() / xtTEE caller -- is enough to land a pskbcopy()'d skb in espinput() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes.

Set SKBFLSHAREDFRAG on the destination whenever frag descriptors were actually moved from the source. skbcopy() and skbcopyexpand() share skbcopyheader() too but linearize all paged data into freshly allocated head storage and emerge with nrfrags == 0, so skbhasshared_frag() returns false on its own; they need no change.

The same omission exists in skbgroreceive() and skbgroreceivelist(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the headfrag + memcpy path); the latter chains the incoming skb whole onto p's fraglist. Downstream skbsegment() reads only skbshinfo(p)->flags, and skbsegment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker.

The same omission also exists in tcpclonepayload(), which builds an MTU probe skb by moving frag descriptors from skbs on skwritequeue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently.

The same omission exists in skbsegment(): the per-iteration flag merge takes only headskb's flag, and the inner switch that rebinds fragskb to listskb on headskb-frags exhaustion does not fold the new fragskb's flag into nskb. Fold fragskb's flag at both sites so segments drawing frags from fraglist members carry the marker.(CVE-2026-43503)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix null-ptr-deref in l2capsockstatechangecb()

Add the same NULL guard already present in l2capsockresumecb() and l2capsockreadycb().(CVE-2026-45834)

In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix slab-use-after-free in qd_put

Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously") started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2qdshrink_scan) tried to access already-freed objects on the LRU list.

Fix this by removing qd objects from the LRU list before freeing them in qd_put().

Initial fix from Deepanshu Kartikey <(CVE-2026-45861)

In the Linux kernel, the following vulnerability has been resolved:

usb: cdns3: fix role switching during resume

If the role change while we are suspended, the cdns3 driver switches to the new mode during resume. However, switching to host mode in this context causes a NULL pointer dereference.

The host role's start() operation registers a xhci-hcd device, but its probe is deferred while we are in the resume path. The host role's resume() operation assumes the xhci-hcd device is already probed, which is not the case, leading to the dereference. Since the start() operation of the new role is already called, the resume operation can be skipped.

So skip the resume operation for the new role if a role switch occurs during resume. Once the resume sequence is complete, the xhci-hcd device can be probed in case of host mode.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 Mem abort info: ... Data abort info: ... [0000000000000208] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT Hardware name: Texas Instruments J7200 EVM (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhcdisprimaryhcd+0x0/0x1c lr : cdnshostresume+0x24/0x5c ... Call trace: usbhcdisprimaryhcd+0x0/0x1c (P) cdnsresume+0x6c/0xbc cdns3controllerresume.isra.0+0xe8/0x17c cdns3platresume+0x18/0x24 platformpmresume+0x2c/0x68 dpmruncallback+0x90/0x248 deviceresume+0x100/0x24c dpmresume+0x190/0x2ec dpmresumeend+0x18/0x34 suspenddevicesandenter+0x2b0/0xa44 pmsuspend+0x16c/0x5fc statestore+0x80/0xec kobjattrstore+0x18/0x2c sysfskfwrite+0x7c/0x94 kernfsfopwriteiter+0x130/0x1dc vfswrite+0x240/0x370 ksys_write+0x70/0x108 _arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0x108 el0t64synchandler+0xa0/0xe4 el0t64sync+0x198/0x19c Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401) ---[ end trace 0000000000000000 ]---(CVE-2026-45911)

In the Linux kernel, the following vulnerability has been resolved:

erofs: fix inline data read failure for ztailpacking pclusters

Compressed folios for ztailpacking pclusters must be valid before adding these pclusters to I/O chains. Otherwise, zerofsdecompress_pcluster() may assume they are already valid and then trigger a NULL pointer dereference.

It is somewhat hard to reproduce because the inline data is in the same block as the tail of the compressed indexes, which are usually read just before. However, it may still happen if a fatal signal arrives while readmappingfolio() is running, as shown below:

erofs: (device dm-1): zerofspcluster_begin: failed to get inline data -4 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008

...

pc : zerofsdecompressqueue+0x4c8/0xa14 lr : zerofsdecompressqueue+0x160/0xa14 sp : ffffffc08b3eb3a0 x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000 x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001 x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700 x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098 x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004 x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9 x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: zerofsdecompressqueue+0x4c8/0xa14 zerofsrunqueue+0x908/0x97c zerofsreadfolio+0x128/0x228 filemapreadfolio+0x68/0x128 filemapgetpages+0x44c/0x8b4 filemapread+0x12c/0x5b8 genericfilereaditer+0x4c/0x15c doiterreadvwritev+0x188/0x1e0 vfsiterread+0xac/0x1a4 backingfilereaditer+0x170/0x34c ovlreaditer+0xf0/0x140 vfsread+0x28c/0x344 ksysread+0x80/0xf0 _arm64sysread+0x24/0x34 invokesyscall+0x60/0x114 el0svccommon+0x88/0xe4 doel0svc+0x24/0x30 el0svc+0x40/0xa8 el0t64synchandler+0x70/0xbc el0t64sync+0x1bc/0x1c0

Fix this by reading the inline data before allocating and adding the pclusters to the I/O chains.(CVE-2026-45943)

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix memory leak in amdgpuacpienumerate_xcc()

In amdgpuacpienumeratexcc(), if amdgpuacpidevinit() returns -ENOMEM, the function returns directly without releasing the allocated xcc_info, resulting in a memory leak.

Fix this by ensuring that xcc_info is properly freed in the error paths.

Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-45947)

In the Linux kernel, the following vulnerability has been resolved:

gfs2: fix memory leaks in gfs2fillsuper error path

Fix two memory leaks in the gfs2fillsuper() error handling path when transitioning a filesystem to read-write mode fails.

First leak: kthread objects (threadstruct, taskstruct, etc.) When gfs2freezelockshared() fails after initthreads() succeeds, the created kernel threads (logd and quotad) are never destroyed. This occurs because the failpernode label doesn't call gfs2destroythreads().

Second leak: quota bitmap buffer (8192 bytes) When gfs2makefsrw() fails after gfs2quota_init() succeeds but before other operations complete, the allocated quota bitmap is never freed.

The fix moves thread cleanup to the failpernode label to handle all error paths uniformly. gfs2destroythreads() is safe to call unconditionally as it checks for NULL pointers. Quota cleanup is added in gfs2makefs_rw() to properly handle the withdrawal case where quota initialization succeeds but the filesystem is then withdrawn.

Thread leak backtrace (gfs2freezelockshared failure): unreferenced object 0xffff88801d7bca80 (size 4480): copyprocess+0x3a1/0x4670 kernel/fork.c:2422 kernelclone+0xf3/0x6e0 kernel/fork.c:2779 kthreadcreateonnode+0x100/0x150 kernel/kthread.c:478 initthreads+0xab/0x350 fs/gfs2/opsfstype.c:611 gfs2fillsuper+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265

Quota leak backtrace (gfs2makefsrw failure): unreferenced object 0xffff88812de7c000 (size 8192): gfs2quotainit+0xe5/0x820 fs/gfs2/quota.c:1409 gfs2makefsrw+0x7a/0xe0 fs/gfs2/super.c:149 gfs2fillsuper+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275(CVE-2026-45961)

In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Fix NULL pointer dereference in acpievaddressspacedispatch()

Cover a missed execution path with a new check.(CVE-2026-45982)

In the Linux kernel, the following vulnerability has been resolved:

erofs: fix unsigned underflow in zerofslz4handleoverlap()

Some crafted images can have illegal (!partialdecoding && mllen < mplen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: "outpages - inpages" wraps to a large value and the subsequent rq->out[] access reads past the decompressedpages array.

However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path.

Let's add an additional check to fix this for backporting.

Reproducible image (base64-encoded gzipped blob):

H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA=

$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1(CVE-2026-45999)

In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running. The Linux kernel CVE team has assigned CVE-2026-46044 to this issue.(CVE-2026-46044)

In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retryalignedread() When retryalignedread() encounters an overlapped stripe, it releases the stripe via raid5releasestripe() which puts it on the lockless releasedstripes llist. In the next raid5d loop iteration, releasestripelist() drains the stripe onto handlelist (since STRIPEHANDLE is set by the original IO), but retryalignedread() runs before handleactivestripes() and removes the stripe from handlelist via findgetstripe() -> listdelinit(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using _releasestripe() with tempinactivelist instead of raid5releasestripe() in the failure path, so the stripe does not go through the releasedstripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handlestripe(). The Linux kernel CVE team has assigned CVE-2026-46051 to this issue.(CVE-2026-46051)

In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nestedsvml2tlbflush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs] The Linux kernel CVE team has assigned CVE-2026-46076 to this issue.(CVE-2026-46076)

In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of sizeof(struct erofs_dirent) as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com The Linux kernel CVE team has assigned CVE-2026-46078 to this issue.(CVE-2026-46078)

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@] The Linux kernel CVE team has assigned CVE-2026-46082 to this issue.(CVE-2026-46082)

In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: take vmappurgelock in shrinker decayvapool_node() can be invoked concurrently from two paths: __purgevmaparealazy() when pools are being purged, and the shrinker via vmapnodeshrinkscan(). However, decayvapoolnode() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks. Protect decayvapoolnode() by taking vmappurgelock in the shrinker path to ensure serialization with purge users. The Linux kernel CVE team has assigned CVE-2026-46093 to this issue.(CVE-2026-46093)

In the Linux kernel, the following vulnerability has been resolved:mm/damon/sysfs-schemes: protect memcgpath kfree() with damonsysfslockPatch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg]path".Reads of 'memcgpath' and 'path' files in DAMON sysfs interface could racewith their writes, results in use-after-free. Fix those.This patch (of 2):damonsysfsschemefilter->mmecgpath can be read and written by users,via DAMON sysfs memcgpath file. It can also be indirectly read, for theparameters {on,off}line committing to DAMON. The reads for parameterscommitting are protected by damonsysfslock to avoid the sysfs filesbeing destroyed while any of the parameters are being read. But theuser-driven direct reads and writes are not protected by any lock, whilethe write is deallocating the memcgpath-pointing buffer. As a result,the readers could read the already freed buffer (user-after-free). Notethat the user-reads don't race when the same open file is used by thewriter, due to kernfs's open file locking. Nonetheless, doing the readsand writes with separate open files would be common. Fix it by protectingboth the user-direct reads and writes with damonsysfs_lock.(CVE-2026-46121)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hcievent: Fix OOB read and infinite loop in hcilecreatebigcompleteevt

hcilecreatebigcompleteevt() iterates over BTBOUND connections for a BIG handle using a while loop, accessing ev->bishandle[i++] on each iteration. However, there is no check that i stays within ev->numbis before the array access.

When a controller sends a LECreateBIGComplete event with fewer bishandle entries than there are BTBOUND connections for that BIG, or with numbis=0, the loop reads beyond the valid bishandle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCICONNHANDLEMAX (0x0EFF), hciconnsethandle() rejects them and the connection remains in BTBOUND state. The same connection is then found again by hciconnhashlookupbigstate(), creating an infinite loop with hcidev_lock held.

Fix this by terminating the BIG if in case not all BIS could be setup properly.(CVE-2026-46138)

In the Linux kernel, vports are used concurrently and protected by RCU, so netdevput() must happen after the RCU grace period. The rtnldeletelink() must happen under RTNL and cannot be executed in RCU context. Calling synchronizenet() while holding RTNL is not good for performance and system stability, so calling netdevput() in RCU call is the right solution. However, when the device is deleted, rtnlunlock() calls netdevruntodo() and blocks until all references are gone. In the current code, this means that callrcu() is never reached, the vport is never freed, and the reference is never released, causing a self-deadlock on device removal. The fix moves the rcucall() before rtnlunlock(), so the scheduled RCU callback will be executed when synchronizenet() is called from rtnlunlock()->netdevrun_todo() while RTNL itself is already released.(CVE-2026-46165)

In the Linux kernel's RISC-V KVM subsystem, when the second kzalloc (hostcontext.vector.datap) fails in kvmriscvvcpuallocvectorcontext, the first allocation (guestcontext.vector.datap) is not freed, causing a memory leak. An attacker can trigger this via ioctl(vmfd, KVMCREATEVCPU), potentially leading to resource exhaustion.(CVE-2026-46171)

In the Linux kernel, the mlx4ibcreatesrq() function fails to release resources allocated by mlx4srq_alloc() in error handling paths, leading to a resource leak. An attacker could exploit this vulnerability to cause resource exhaustion or denial of service.(CVE-2026-46178)

In the Linux kernel, the spinorparamsshow() function uses sizeof(snorfnames) to calculate the array length. Since snorfnames is an array of pointers, sizeof returns the total byte size of the pointer array (elementcount sizeof(void )), which on 64-bit systems is 8 times larger than intended. This causes an out-of-bounds read when a flag bit is set that exceeds the actual element count but falls within the inflated byte-size count. The fix replaces sizeof with ARRAY_SIZE to pass the actual number of elements.(CVE-2026-46190)