crypto: afalg - Disallow concurrent writes in afalgsendmsg

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

tcp: Clear tcpsk(sk)->fastopenrsk in tcpdisconnect().

syzbot reported the splat below where a socket had tcpsk(sk)->fastopenrsk in the TCPESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS:

1. accept() 2. connect(AFUNSPEC) 3. connect() to another destination

As of accept(), sk->skstate is TCPSYNRECV, and tcpdisconnect() changes it to TCPCLOSE and makes connect() possible, which restarts timers.

Since tcpdisconnect() forgot to clear tcpsk(sk)->fastopenrsk, the retransmit timer triggered the warning and the intended packet was not retransmitted.

Let's call reqskfastopenremove() in tcpdisconnect().

[0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcptimer.c:542 tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcpwritetimer (net/ipv4/tcptimer.c:738) calltimerfn (kernel/time/timer.c:1747) runtimers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timerexpireremote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigrhandleremoteup (kernel/time/timermigration.c:944 kernel/time/timermigration.c:1035) walkgroups.isra.0 (kernel/time/timermigration.c:533 (discriminator 1)) tmigrhandleremote (kernel/time/timermigration.c:1096) handlesoftirqs (./arch/x86/include/asm/jumplabel.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irqexitrcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ>

crypto: afalg - Set merge to zero early in afalgsendmsg

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

dmaengine: idxd: Remove improper idxdfree

The call to idxdfree() introduces a duplicate putdevice() leading to a reference count underflow: refcountt: underflow; use-after-free. WARNING: CPU: 15 PID: 4428 at lib/refcount.c:28 refcountwarnsaturate+0xbe/0x110 ... Call Trace: <TASK> idxdremove+0xe4/0x120 [idxd] pcideviceremove+0x3f/0xb0 devicereleasedriverinternal+0x197/0x200 driverdetach+0x48/0x90 busremovedriver+0x74/0xf0 pciunregisterdriver+0x2e/0xb0 idxdexitmodule+0x34/0x7a0 [idxd] dosysdeletemodule.constprop.0+0x183/0x280 dosyscall64+0x54/0xd70 entrySYSCALL64afterhwframe+0x76/0x7e

The idxdunregisterdevices() which is invoked at the very beginning of idxdremove(), already takes care of the necessary putdevice() through the following call path: idxdunregisterdevices() -> deviceunregister() -> putdevice()

In addition, when CONFIGDEBUGKOBJECTRELEASE is enabled, putdevice() may trigger asynchronous cleanup via scheduledelayedwork(). If idxdfree() is called immediately after, it can result in a use-after-free.

Remove the improper idxdfree() to avoid both the refcount underflow and potential memory corruption during module unload.

fs: writeback: fix use-after-free in markinodedirty()

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

net: rose: include node references in roseneigh refcount

Current implementation maintains two separate reference counting mechanisms: the 'count' field in struct roseneigh tracks references from rosenode structures, while the 'use' field (now refcountt) tracks references from rosesock.

This patch merges these two reference counting systems using 'use' field for proper reference management. Specifically, this patch adds incrementing and decrementing of roseneigh->use when roseneigh->count is incremented or decremented.

This patch also modifies rosertfree(), rosertdevicedown() and roseclearroute() to properly release references to roseneigh objects before freeing a rosenode through roseremovenode().

These changes ensure roseneigh structures are properly freed only when all references, including those from rosenode structures, are released. As a result, this resolves a slab-use-after-free issue reported by Syzbot.

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

net: rose: convert 'use' field to refcountt

The 'use' field in struct roseneigh is used as a reference counter but lacks atomicity. This can lead to race conditions where a roseneigh structure is freed while still being referenced by other code paths.

For example, when roseneigh->use becomes zero during an ioctl operation via rosertioctl(), the structure may be removed while its timer is still active, potentially causing use-after-free issues.

This patch changes the type of 'use' from unsigned short to refcountt and updates all code paths to use roseneighhold() and roseneighput() which operate reference counts atomically.

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

net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6CSUM

When performing Generic Segmentation Offload (GSO) on an IPv6 packet that contains extension headers, the kernel incorrectly requests checksum offload if the egress device only advertises NETIFFIPV6CSUM feature, which has a strict contract: it supports checksum offload only for plain TCP or UDP over IPv6 and explicitly does not support packets with extension headers. The current GSO logic violates this contract by failing to disable the feature for packets with extension headers, such as those used in GREoIPv6 tunnels.

This violation results in the device being asked to perform an operation it cannot support, leading to a skbwarnbadoffload warning and a collapse of network throughput. While device TSO/USO is correctly bypassed in favor of software GSO for these packets, the GSO stack must be explicitly told not to request checksum offload.

Mask NETIFFIPV6CSUM, NETIFFTSO6 and NETIFFGSOUDPL4 in gsofeaturescheck if the IPv6 header contains extension headers to compute checksum in software.

The exception is a BIG TCP extension, which, as stated in commit 68e068cabd2c6c53 ("net: reenable NETIFFIPV6CSUM offload for BIG TCP packets"): "The feature is only enabled on devices that support BIG TCP TSO. The header is only present for PFPACKET taps like tcpdump, and not transmitted by physical devices."

kernel log output (truncated): WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skbwarnbadoffload+0x81/0x140 ... Call Trace: <TASK> skbchecksumhelp+0x12a/0x1f0 validatexmitskb+0x1a3/0x2d0 validatexmitskblist+0x4f/0x80 schdirectxmit+0x1a2/0x380 devxmitskb+0x242/0x670 devqueuexmit+0x3fc/0x7f0 ip6finishoutput2+0x25e/0x5d0 ip6finishoutput+0x1fc/0x3f0 ip6tnlxmit+0x608/0xc00 [ip6tunnel] ip6gretunnelxmit+0x1c0/0x390 [ip6gre] devhardstartxmit+0x63/0x1c0 devqueuexmit+0x6d0/0x7f0 ip6finishoutput2+0x214/0x5d0 ip6finishoutput+0x1fc/0x3f0 ip6xmit+0x2ca/0x6f0 ip6finishoutput+0x1fc/0x3f0 ip6xmit+0x2ca/0x6f0 inet6cskxmit+0xeb/0x150 tcptransmitskb+0x555/0xa80 tcpwritexmit+0x32a/0xe90 tcpsendmsglocked+0x437/0x1110 tcpsendmsg+0x2f/0x50 ... skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00 skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00 skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00 skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00 skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00 skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9 skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01 skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a

fs/buffer: fix use-after-free when call bhread() helper

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

net: usb: asixdevices: Fix PHY address mask in MDIO bus initialization

Syzbot reported shift-out-of-bounds exception on MDIO bus initialization.

The PHY address should be masked to 5 bits (0-31). Without this mask, invalid PHY addresses could be used, potentially causing issues with MDIO bus operations.

Fix this by masking the PHY address with 0x1f (31 decimal) to ensure it stays within the valid range.

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

netfilter: nfreject: don't leak dst refcount for loopback packets

recent patches to add a WARN() when replacing skb dst entry found an old bug:

WARNING: include/linux/skbuff.h:1165 skbdstcheckunset include/linux/skbuff.h:1164 [inline] WARNING: include/linux/skbuff.h:1165 skbdstset include/linux/skbuff.h:1210 [inline] WARNING: include/linux/skbuff.h:1165 nfrejectfillskbdst+0x2a4/0x330 net/ipv4/netfilter/nfrejectipv4.c:234 [..] Call Trace: nfsendunreach+0x17b/0x6e0 net/ipv4/netfilter/nfrejectipv4.c:325 nftrejectineteval+0x4bc/0x690 net/netfilter/nftrejectinet.c:27 exprcallopseval net/netfilter/nftablescore.c:237 [inline] ..

This is because blamed commit forgot about loopback packets. Such packets already have a dstentry attached, even at PREROUTING stage.

Instead of checking hook just check if the skb already has a route attached to it.

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

mISDN: hfcpci: Fix warning when deleting uninitialized timer

With CONFIGDEBUGOBJECTSTIMERS 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] ? lockacquire+0xdea/0x1c70 [ 250.240369] trytodeltimersync+0x69/0x140 [ 250.241172] ? pfxtrytodeltimersync+0x10/0x10 [ 250.242058] ? timerdeletesync+0xc6/0x120 [ 250.242842] ? lockacquire+0x30/0x80 [ 250.243474] ? timerdeletesync+0xc6/0x120 [ 250.244262] timerdeletesync+0x98/0x120 [ 250.245015] HFCcleanup+0x10/0x20 [hfcpci] [ 250.245704] dosysdeletemodule+0x348/0x510 [ 250.246461] ? pfxdosysdeletemodule+0x10/0x10 [ 250.247338] dosyscall64+0xc1/0x360 [ 250.247924] entrySYSCALL64afterhwframe+0x77/0x7f

Fix this by initializing hfctl timer with DEFINETIMER macro. Also, use modtimer instead of manual timeout update.

efivarfs: Fix slab-out-of-bounds in efivarfsdcompare

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

wifi: cfg80211: fix use-after-free in cmpbss()

Following bssfree() quirk introduced in commit 776b3580178f ("cfg80211: track hidden SSID networks properly"), adjust cfg80211updateknownbss() to free the last beacon frame elements only if they're not shared via the corresponding 'hiddenbeaconbss' pointer.

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

wifi: cfg80211: sme: cap SSID length in cfg80211connectresult()

If the ssid->datalen is more than IEEE80211MAXSSIDLEN (32) it would lead to memory corruption so add some bounds checking.

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

wifi: brcmfmac: fix use-after-free when rescheduling brcmfbtcoexinfo work

The brcmfbtcoexdetach() only shuts down the btcoex timer, if the flag timeron is false. However, the brcmfbtcoextimerfunc(), which runs as timer handler, sets timeron to false. This creates critical race conditions:

1.If brcmfbtcoexdetach() is called while brcmfbtcoextimerfunc() is executing, it may observe timeron as false and skip the call to timershutdownsync().

2.The brcmfbtcoextimerfunc() may then reschedule the brcmfbtcoexinfo worker after the cancelworksync() has been executed, resulting in use-after-free bugs.

The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmfbtcoexinfo struct is freed relative to the execution of its worker thread.

Scenario 1: Freed before the worker is scheduled

The brcmfbtcoexinfo is deallocated before the worker is scheduled. A race condition can occur when schedulework(&btlocal->work) is called after the target memory has been freed. The sequence of events is detailed below:

CPU0 | CPU1 brcmfbtcoexdetach | brcmfbtcoextimerfunc | btlocal->timeron = false; if (cfg->btcoex->timeron) | ... | cancelworksync(); | ... | kfree(cfg->btcoex); // FREE | | schedulework(&btlocal->work); // USE

Scenario 2: Freed after the worker is scheduled

The brcmfbtcoexinfo is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmfbtcoexhandler() — such as the containerof macro and subsequent dereferences of the brcmfbtcoexinfo object will cause a use-after-free access. The following timeline illustrates this scenario:

CPU0 | CPU1 brcmfbtcoexdetach | brcmfbtcoextimerfunc | btlocal->timeron = false; if (cfg->btcoex->timeron) | ... | cancelworksync(); | ... | schedulework(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmfbtcoexhandler() // Worker / | btci = containerof(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| / |

To resolve the race conditions, drop the conditional check and call timershutdownsync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timeron state is then set to false.

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

mm/memory-failure: fix VMBUGONPAGE(PagePoisoned(page)) when unpoison memory

When I did memory failure tests, below panic occurs:

page dumped because: VMBUGONPAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoisonmemory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: <TASK> unpoisonmemory+0x2f3/0x590 simpleattrwritexsigned.constprop.0.isra.0+0xb3/0x110 debugfsattrwrite+0x42/0x60 fullproxywrite+0x5b/0x80 vfswrite+0xd5/0x540 ksyswrite+0x64/0xe0 dosyscall64+0xb9/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 </TASK> Modules linked in: hwpoisoninject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoisonmemory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---

The root cause is that unpoisonmemory() tries to check the PGHWPoison flags of an uninitialized page. So VMBUGONPAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps:

1.Offline memory block:

echo offline > /sys/devices/system/memory/memory12/state

2.Get offlined memory pfn:

page-types -b n -rlN

3.Write pfn to unpoison-pfn

echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn

This scenario can be identified by pfntoonlinepage() returning NULL. And ZONEDEVICE pages are never expected, so we can simply fail if pfntoonlinepage() == NULL to fix the bug.

i40e: remove read access to debugfs files

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

mm/slub: avoid accessing metadata when pointer is invalid in objecterr()

objecterr() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object.

One known path to the crash is when allocconsistencychecks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls objecterr() to report it. The debug code should report and handle the corruption gracefully and not crash in the process.

In case the pointer is NULL or checkvalidpointer() returns false for the pointer, only print the pointer value and skip accessing metadata.

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

iommufd: Fix race during abort for file descriptors

fput() doesn't actually call fileoperations release() synchronously, it puts the file on a work queue and it will be released eventually.

This is normally fine, except for iommufd the file and the iommufdobject are tied to gether. The file has the object as it's privatedata and holds a users refcount, while the object is expected to remain alive as long as the file is.

When the allocation of a new object aborts before installing the file it will fput() the file and then go on to immediately kfree() the obj. This causes a UAF once the workqueue completes the fput() and tries to decrement the users refcount.

Fix this by putting the core code in charge of the file lifetime, and call fputsync() during abort to ensure that release() is called before kfree. fputsync() is a bit too tricky to open code in all the object implementations. Instead the objects tell the core code where the file pointer is and the core will take care of the life cycle.

If the object is successfully allocated then the file will hold a users refcount and the iommufdobject cannot be destroyed.

It is worth noting that close(); ioctl(IOMMUDESTROY); doesn't have an issue because close() is already using a synchronous version of fput().

The UAF looks like this:

BUG: KASAN: slab-use-after-free in iommufdeventqfopsrelease+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 Write of size 4 at addr ffff888059c97804 by task syz.0.46/6164

CPU: 0 UID: 0 PID: 6164 Comm: syz.0.46 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:183 [inline] kasancheckrange+0x100/0x1b0 mm/kasan/generic.c:189 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicfetchsubrelease include/linux/atomic/atomic-instrumented.h:400 [inline] refcountdec include/linux/refcount.h:455 [inline] refcountdec include/linux/refcount.h:476 [inline] iommufdeventqfopsrelease+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 fput+0x402/0xb70 fs/filetable.c:468 taskworkrun+0x14d/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xeb/0x110 kernel/entry/common.c:43 exittousermodeprepare include/linux/irq-entry-common.h:225 [inline] syscallexittousermodework include/linux/entry-common.h:175 [inline] syscallexittousermode include/linux/entry-common.h:210 [inline] dosyscall64+0x41c/0x4c0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f

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

xfrm: xfrmallocspi shouldn't use 0 as SPI

x->id.spi == 0 means "no SPI assigned", but since commit 94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states and add them to the byspi list with this value.

xfrmstatedelete doesn't remove those states from the byspi list, since they shouldn't be there, and this shows up as a UAF the next time we go through the byspi list.

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

iouring: fix incorrect iokiocb reference in iolinkskb

In iolinkskb function, there is a bug where prevnotif is incorrectly assigned using 'nd' instead of 'prevnd'. This causes the context validation check to compare the current notification with itself instead of comparing it with the previous notification.

Fix by using the correct prevnd parameter when obtaining prevnotif.

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

rxrpc: Fix untrusted unsigned subtract

Fix the following Smatch static checker warning:

net/rxrpc/rxgkapp.c:65 rxgkyfsdecodeticket() warn: untrusted unsigned subtract. 'ticketlen - 10 4'

by prechecking the length of what we're trying to extract in two places in the token and decoding for a response packet.

Also use sizeof() on the struct we're extracting rather specifying the size numerically to be consistent with the other related statements.

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

iommu/amd/pgtbl: Fix possible race while increase page table level

The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in allocpte()/fetchpte() operations.

The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level.

But in unmap path (iommuv1unmappages()), fetchpte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increaseaddressspace() is updating pgtable->[root/mode], fetchpte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommuunmap ops to fail and upper layer may retry/log WARNON.

CPU 0 CPU 1 ------ ------ map pages unmap pages allocpte() -> increaseaddressspace() iommuv1unmappages() -> fetchpte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)

Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.

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

gpiolib: acpi: initialize acpigpioinfo struct

Since commit 7c010d463372 ("gpiolib: acpi: Make sure we fill struct acpigpioinfo"), uninitialized acpigpioinfo struct are passed to acpifindgpio() and later in the call stack info->quirks is used in acpipopulategpiolookup. This breaks the i2chidcpi driver:

[ 58.122916] i2chidacpi i2c-UNIW0001:00: HID over i2c has not been provided an Int IRQ [ 58.123097] i2chidacpi i2c-UNIW0001:00: probe with driver i2chidacpi failed with error -22

Fix this by initializing the acpigpioinfo pass to acpifindgpio()

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

wifi: mac80211: increase scanieslen for S1G

Currently the S1G capability element is not taken into account for the scanieslen, which leads to a buffer length validation failure in ieee80211prephwscan() and subsequent WARN in ieee80211startscan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length.

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

igc: don't fail igcprobe() on LED setup error

When igcledsetup() fails, igcprobe() fails and triggers kernel panic in freenetdev() since unregisternetdev() is not called. [1] This behavior can be tested using fault-injection framework, especially the failslab feature. [2]

Since LED support is not mandatory, treat LED setup failures as non-fatal and continue probe with a warning message, consequently avoiding the kernel panic.

[1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:freenetdev+0x278/0x2b0 [...] Call Trace: <TASK> igcprobe+0x370/0x910 localpciprobe+0x3a/0x80 pcideviceprobe+0xd1/0x200 [...]

[2] #!/bin/bash -ex

FAILSLABPATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 STARTADDR=$(grep " igcledsetup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') ENDADDR=$(printf "0x%x" $((STARTADDR + 0x100)))

echo $STARTADDR > $FAILSLABPATH/require-start echo $ENDADDR > $FAILSLABPATH/require-end echo 1 > $FAILSLABPATH/times echo 100 > $FAILSLABPATH/probability echo N > $FAILSLABPATH/ignore-gfp-wait

echo $DEVICE > /sys/bus/pci/drivers/igc/bind

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

wifi: wilc1000: avoid buffer overflow in WID string configuration

Fix the following copy overflow warning identified by Smatch checker.

drivers/net/wireless/microchip/wilc1000/wlancfg.c:184 wilcwlanparseresponseframe() error: 'memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)

This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilccfgstrvals' that is maintained in 'len' field of 'struct wilccfgstr'.

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

um: virtiouml: Fix use-after-free after putdevice in probe

When registervirtiodevice() fails in virtioumlprobe(), the code sets vudev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.

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

qed: Don't collect too many protection override GRC elements

In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer.

This will result in a kernel panic with reason:

BUG: unable to handle kernel paging request at ADDRESS

where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is: phwfn->cdev->dbgfeatures[DBGFEATUREPROTECTIONOVERRIDE].dumpbuf and the size of the buffer is bufsize in the same data structure.

The panic can be arrived at from either the qede Ethernet driver path:

[exception RIP: qedgrcdumpaddrrange+0x108] qedprotectionoverridedump at ffffffffc02662ed [qed] qeddbgprotectionoverridedump at ffffffffc0267792 [qed] qeddbgfeature at ffffffffc026aa8f [qed] qeddbgalldata at ffffffffc026b211 [qed] qedfwfatalreporterdump at ffffffffc027298a [qed] devlinkhealthdodump at ffffffff82497f61 devlinkhealthreport at ffffffff8249cf29 qedreportfatalerror at ffffffffc0272baf [qed] qedesptask at ffffffffc045ed32 [qede] processonework at ffffffff81d19783

or the qedf storage driver path:

[exception RIP: qedgrcdumpaddrrange+0x108] qedprotectionoverridedump at ffffffffc068b2ed [qed] qeddbgprotectionoverridedump at ffffffffc068c792 [qed] qeddbgfeature at ffffffffc068fa8f [qed] qeddbgalldata at ffffffffc0690211 [qed] qedfwfatalreporterdump at ffffffffc069798a [qed] devlinkhealthdodump at ffffffff8aa95e51 devlinkhealthreport at ffffffff8aa9ae19 qedreportfatalerror at ffffffffc0697baf [qed] qedhwerrnotify at ffffffffc06d32d7 [qed] qedspqpost at ffffffffc06b1011 [qed] qedfcoedestroyconn at ffffffffc06b2e91 [qed] qedfcleanupfcport at ffffffffc05e7597 [qedf] qedfrporteventhandler at ffffffffc05e7bf7 [qedf] fcrportwork at ffffffffc02da715 [libfc] processonework at ffffffff8a319663

Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.