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

netfilter: nftables: always release netdev hooks from notifier

This reverts "netfilter: nftables: skip netdev events generated on netns removal".

The problem is that when a veth device is released, the veth release callback will also queue the peer netns device for removal.

Its possible that the peer netns is also slated for removal. In this case, the device memory is already released before the preexit hook of the peer netns runs:

BUG: KASAN: slab-use-after-free in nfhookentryhead+0x1b8/0x1d0 Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45 Workqueue: netns cleanupnet Call Trace: nfhookentryhead+0x1b8/0x1d0 nfunregisternethook+0x76/0x510 nftnetdevunregisterhooks+0xa0/0x220 nftreleasehook+0x184/0x490 nftablespreexitnet+0x12f/0x1b0 ..

Order is: 1. First netns is released, vethdellink() queues peer netns device for removal 2. peer netns is queued for removal 3. peer netns device is released, unreg event is triggered 4. unreg event is ignored because netns is going down 5. preexit hook calls nftnetdevunregisterhooks but device memory might be free'd already.

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

RDMA/efa: Fix wrong resources deallocation order

When trying to destroy QP or CQ, we first decrease the refcount and potentially free memory regions allocated for the object and then request the device to destroy the object. If the device fails, the object isn't fully destroyed so the user/IB core can try to destroy the object again which will lead to underflow when trying to decrease an already zeroed refcount.

Deallocate resources in reverse order of allocating them to safely free them.

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

Bluetooth: L2CAP: Fix potential user-after-free

This fixes all instances of which requires to allocate a buffer calling allocskb which may release the chan lock and reacquire later which makes it possible that the chan is disconnected in the meantime.

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

net/sched: flower: fix filter idr initialization

The cited commit moved idr initialization too early in flchange() which allows concurrent users to access the filter that is still being initialized and is in inconsistent state, which, in turn, can cause NULL pointer dereference [0]. Since there is no obvious way to fix the ordering without reverting the whole cited commit, alternative approach taken to first insert NULL pointer into idr in order to allocate the handle but still cause flget() to return NULL and prevent concurrent users from seeing the filter while providing miss-to-action infrastructure with valid handle id early in flchange().

[ 152.434728] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN [ 152.436163] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 152.437269] CPU: 4 PID: 3877 Comm: tc Not tainted 6.3.0-rc4+ #5 [ 152.438110] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 152.439644] RIP: 0010:fldumpkey+0x8b/0x1d10 [clsflower] [ 152.440461] Code: 01 f2 02 f2 c7 40 08 04 f2 04 f2 c7 40 0c 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 00 01 00 00 48 89 c8 48 c1 e8 03 <0f> b6 04 10 84 c0 74 08 3c 03 0f 8e 98 19 00 00 8b 13 85 d2 74 57 [ 152.442885] RSP: 0018:ffff88817a28f158 EFLAGS: 00010246 [ 152.443851] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 152.444826] RDX: dffffc0000000000 RSI: ffffffff8500ae80 RDI: ffff88810a987900 [ 152.445791] RBP: ffff888179d88240 R08: ffff888179d8845c R09: ffff888179d88240 [ 152.446780] R10: ffffed102f451e48 R11: 00000000fffffff2 R12: ffff88810a987900 [ 152.447741] R13: ffffffff8500ae80 R14: ffff88810a987900 R15: ffff888149b3c738 [ 152.448756] FS: 00007f5eb2a34800(0000) GS:ffff88881ec00000(0000) knlGS:0000000000000000 [ 152.449888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 152.450685] CR2: 000000000046ad19 CR3: 000000010b0bd006 CR4: 0000000000370ea0 [ 152.451641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 152.452628] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 152.453588] Call Trace: [ 152.454032] <TASK> [ 152.454447] ? netlinksendmsg+0x7a1/0xcb0 [ 152.455109] ? socksendmsg+0xc5/0x190 [ 152.455689] ? syssendmsg+0x535/0x6b0 [ 152.456320] ? syssendmsg+0xeb/0x170 [ 152.456916] ? dosyscall64+0x3d/0x90 [ 152.457529] ? entrySYSCALL64afterhwframe+0x46/0xb0 [ 152.458321] ? syssendmsg+0xeb/0x170 [ 152.458958] ? syssendmsg+0xb5/0x140 [ 152.459564] ? dosyscall64+0x3d/0x90 [ 152.460122] ? entrySYSCALL64afterhwframe+0x46/0xb0 [ 152.460852] ? fldumpkeyoptions.part.0+0xea0/0xea0 [clsflower] [ 152.461710] ? rawspinlock+0x7a/0xd0 [ 152.462299] ? rawreadlockirq+0x30/0x30 [ 152.462924] ? nlaput+0x15e/0x1c0 [ 152.463480] fldump+0x228/0x650 [clsflower] [ 152.464112] ? fltmpltdump+0x210/0x210 [clsflower] [ 152.464854] ? kmemcacheallocnode+0x1a7/0x330 [ 152.465592] ? nlaput+0x15e/0x1c0 [ 152.466160] tcffillnode+0x515/0x9a0 [ 152.466766] ? tcsetupoffloadaction+0xf0/0xf0 [ 152.467463] ? allocskb+0x13c/0x2a0 [ 152.468067] ? buildskbaround+0x330/0x330 [ 152.468814] ? flget+0x107/0x1a0 [clsflower] [ 152.469503] tcdeltfilter+0x718/0x1330 [ 152.470115] ? isbpftextaddress+0xa/0x20 [ 152.470765] ? tcctlchain+0xee0/0xee0 [ 152.471335] ? kerneltextaddress+0xe/0x30 [ 152.471948] ? unwindgetreturnaddress+0x56/0xa0 [ 152.472639] ? thawtask+0x150/0x150 [ 152.473218] ? archstackwalk+0x98/0xf0 [ 152.473839] ? stackdepotsave+0x35/0x4c0 [ 152.474501] ? stacktracesave+0x91/0xc0 [ 152.475119] ? securitycapable+0x51/0x90 [ 152.475741] rtnetlinkrcvmsg+0x2c1/0x9d0 [ 152.476387] ? rtnlcalcit.isra.0+0x2b0/0x2b0 [ 152.477042] ---truncated---

ALSA: usb-audio: Prevent excessive number of frames

functionfs: fix the open/removal races

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

accel/ivpu: Fix page fault in ivpubounbindallbosfromcontext()

Don't add BO to the vdev->bolist in ivpugemcreateobject(). When failure happens inside drmgemshmemcreate(), the BO is not fully created and ivpugembofree() callback will not be called causing a deleted BO to be left on the list.

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

wifi: ath12k: Fix MSDU buffer types handling in RX error path

Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12khaldescreoparseerr(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks.

Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPLSILICONZ-1

amd/amdkfd: enhance kfd process check in switch partition

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

ceph: fix crash in processv2sparseread() for encrypted directories

The crash in processv2sparseread() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps:

sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,msmode=secure

(1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp areadecrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=rawkey --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/areadecrypted.tar (7) Issue has been triggered

[ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messengerv2.c:865 cephconv2tryread+0x4b39/0x72f0 [ 408.072267] Modules linked in: intelraplmsr intelraplcommon inteluncorefrequencycommon intelpmccore pmttelemetry pmtdiscovery pmtclass intelpmcssramtelemetry intelvsec kvmintel joydev kvm irqbypass polyvalclmulni ghashclmulniintel aesniintel rapl inputleds psmouse serioraw i2cpiix4 vga16fb bochs vgastate i2csmbus floppy machid qemufwcfg pataacpi schfqcodel rbd msr parportpc ppdev lp parport efipstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr cephconworkfn [ 408.072314] RIP: 0010:cephconv2tryread+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] <TASK> [ 408.072340] ? schedclocknoinstr+0x9/0x10 [ 408.072344] ? pfxcephconv2tryread+0x10/0x10 [ 408.072347] ? rawspinunlock+0xe/0x40 [ 408.072349] ? finishtaskswitch.isra.0+0x15d/0x830 [ 408.072353] ? kasancheckwrite+0x14/0x30 [ 408.072357] ? mutexlock+0x84/0xe0 [ 408.072359] ? pfxmutexlock+0x10/0x10 [ 408.072361] cephconworkfn+0x27e/0x10e0 [ 408.072364] ? metricdelayedwork+0x311/0x2c50 [ 408.072367] processonework+0x611/0xe20 [ 408.072371] ? kasancheckwrite+0x14/0x30 [ 408.072373] workerthread+0x7e3/0x1580 [ 408.072375] ? pfxrawspinlockirqsave+0x10/0x10 [ 408.072378] ? pfxworkerthread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? pfxrawspinlockirq+0x10/0x10 [ 408.072385] ? pfxkthread+0x10/0x10 [ 408.072387] ? kasancheckwrite+0x14/0x30 [ 408.072389] ? recalcsigpending+0x160/0x220 [ 408.072392] ? rawspinunlockirq+0xe/0x50 [ 408.072394] ? calculatesigpending+0x78/0xb0 [ 408.072395] ? pfxkthread+0x10/0x10 [ 408.072397] retfromfork+0x2b6/0x380 [ 408.072400] ? pfxkthread+0x10/0x10 [ 408.072402] retfromforkasm+0x1a/0x30 [ 408.072406] </TASK> [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---

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

locking/spinlock/debug: Fix data-race in dorawwritelock

KCSAN reports:

BUG: KCSAN: data-race in dorawwritelock / dorawwritelock

write (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: dorawwritelock+0x120/0x204 rawwritelockirq doexit callusermodehelperexecasync retfromfork

read to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: dorawwritelock+0x88/0x204 rawwritelockirq doexit callusermodehelperexecasync retfromfork

value changed: 0xffffffff -> 0x00000001

Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111

Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") has adressed most of these races, but seems to be not consistent/not complete.

From dorawwritelock() only debugwritelockafter() part has been converted to WRITEONCE(), but not debugwritelockbefore() part. Do it now.

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 headerops.

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 teamdevtypecheckchange.

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

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

spi: ch341: fix out-of-bounds memory access in ch341transferone

Discovered by Atuin - Automated Vulnerability Discovery Engine.

The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header.

When copying data from 'trans->txbuf' to 'ch341->txbuf + 1', using 'len' as the length is incorrect because:

1. It causes an out-of-bounds read from 'trans->txbuf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->txbuf' if 'len' is CH341PACKETLENGTH (32). Writing 32 bytes to ch341->txbuf + 1 overflows the buffer.

Fix this by copying 'len - 1' bytes.

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

perf/core: Fix refcount bug and potential UAF in perfmmap

Syzkaller reported a refcountt: addition on 0; use-after-free warning in perfmmap.

The issue is caused by a race condition between a failing mmap() setup and a concurrent mmap() on a dependent event (e.g., using output redirection).

In perfmmap(), the ringbuffer (rb) is allocated and assigned to event->rb with the mmapmutex held. The mutex is then released to perform maprange().

If maprange() fails, perfmmapclose() is called to clean up. However, since the mutex was dropped, another thread attaching to this event (via inherited events or output redirection) can acquire the mutex, observe the valid event->rb pointer, and attempt to increment its reference count. If the cleanup path has already dropped the reference count to zero, this results in a use-after-free or refcount saturation warning.

Fix this by extending the scope of mmapmutex to cover the maprange() call. This ensures that the ring buffer initialization and mapping (or cleanup on failure) happens atomically effectively, preventing other threads from accessing a half-initialized or dying ring buffer.

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

RDMA/siw: Fix potential NULL pointer dereference in header processing

If siwgethdr() returns -EINVAL before setrxfpducontext(), qp->rxfpdu can be NULL. The error path in siwtcprxdata() dereferences qp->rxfpdu->moreddpsegs without checking, which may lead to a NULL pointer deref. Only check moreddpsegs when rxfpdu is present.

KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siwtcprxdata+0x13ad/0x1e50

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

RDMA/umad: Reject negative datalen in ibumadwrite

ibumadwrite computes datalen from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, datalen can become negative and reach ibcreatesendmad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in allocsendrmpplist().

Add an explicit check to reject negative datalen before creating the send buffer.

KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ibcreatesendmad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spraythread/102 [ 211.365867] ibcreatesendmad+0xa01/0x11b0 [ 211.365887] ibumadwrite+0x853/0x1c80

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

smb: client: split cachedfid bitfields to avoid shared-byte RMW races

isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x8664), so updating one flag can restore stale values of the others.

A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | ISOPEN) -> reintroduces cleared bits

To avoid this class of races, convert these flags to separate bool fields.

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

net/sched: clsu32: use skbheaderpointercareful()

skbheaderpointer() does not fully validate negative @offset values.

Use skbheaderpointercareful() instead.

GangMin Kim provided a report and a repro fooling u32classify():

BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221

ALSA: aloop: Fix racy access at PCM trigger

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

nvmet: fix race in nvmetbiodone() leading to NULL pointer dereference

There is a race condition in nvmetbiodone() that can cause a NULL pointer dereference in blkcgroupbiostart():

1. nvmetbiodone() is called when a bio completes 2. nvmetreqcomplete() is called, which invokes req->ops->queueresponse(req) 3. The queueresponse callback can re-queue and re-submit the same request 4. The re-submission reuses the same inlinebio from nvmetreq 5. Meanwhile, nvmetreqbioput() (called after nvmetreqcomplete) invokes biouninit() for inlinebio, which sets bio->biblkg to NULL 6. The re-submitted bio enters submitbionoacctnocheck() 7. blkcgroupbiostart() dereferences bio->biblkg, causing a crash:

BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode RIP: 0010:blkcgroupbiostart+0x10/0xd0 Call Trace: submitbionoacctnocheck+0x44/0x250 nvmetbdevexecuterw+0x254/0x370 [nvmet] processonework+0x193/0x3c0 workerthread+0x281/0x3a0

Fix this by reordering nvmetbiodone() to call nvmetreqbioput() BEFORE nvmetreqcomplete(). This ensures the bio is cleaned up before the request can be re-submitted, preventing the race condition.

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

bonding: limit BONDMODE8023AD to Ethernet devices

BONDMODE8023AD makes sense for ARPHRDETHER only.

syzbot reported:

BUG: KASAN: global-out-of-bounds in hwaddrcreate net/core/devaddrlists.c:63 [inline] BUG: KASAN: global-out-of-bounds in hwaddraddex+0x25d/0x760 net/core/devaddrlists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497

CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> dumpstacklvl+0xe8/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:-1 [inline] kasancheckrange+0x2b0/0x2c0 mm/kasan/generic.c:200 asanmemcpy+0x29/0x70 mm/kasan/shadow.c:105 hwaddrcreate net/core/devaddrlists.c:63 [inline] hwaddraddex+0x25d/0x760 net/core/devaddrlists.c:118 devmcadd net/core/devaddrlists.c:868 [inline] devmcadd+0xa1/0x120 net/core/devaddrlists.c:886 bondenslave+0x2b8b/0x3ac0 drivers/net/bonding/bondmain.c:2180 dosetmaster+0x533/0x6d0 net/core/rtnetlink.c:2963 dosetlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnlchangelink net/core/rtnetlink.c:3776 [inline] rtnlnewlink net/core/rtnetlink.c:3935 [inline] rtnlnewlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlinkrcvmsg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlinkrcvskb+0x208/0x470 net/netlink/afnetlink.c:2550 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x82f/0x9e0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x805/0xb30 net/netlink/afnetlink.c:1894 socksendmsgnosec net/socket.c:727 [inline] socksendmsg+0x21c/0x270 net/socket.c:742 syssendmsg+0x505/0x820 net/socket.c:2592 syssendmsg+0x21f/0x2a0 net/socket.c:2646 syssendmsg+0x164/0x220 net/socket.c:2678 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0x1dc/0x560 arch/x86/entry/syscall32.c:307 dofastsyscall32+0x34/0x80 arch/x86/entry/syscall32.c:332 entrySYSENTERcompatafterhwframe+0x84/0x8e </TASK>

The buggy address belongs to the variable: lacpdumcastaddr+0x0/0x40

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

gue: Fix skb memleak with inner IP protocol 0.

syzbot reported skb memleak below. [0]

The repro generated a GUE packet with its inner protocol 0.

gueudprecv() returns -guehdr->protoctype for "resubmit" in ipprotocoldeliverrcu(), but this only works with non-zero protocol number.

Let's drop such packets.

Note that 0 is a valid number (IPv6 Hop-by-Hop Option).

I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer:

no error resubmit HOPOPT

[0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4958 [inline] slaballocnode mm/slub.c:5263 [inline] kmemcacheallocnoprof+0x3b4/0x590 mm/slub.c:5270 buildskb+0x23/0x60 net/core/skbuff.c:474 buildskb+0x20/0x190 net/core/skbuff.c:490 tunbuildskb drivers/net/tun.c:1541 [inline] tunbuildskb+0x4a1/0xa40 drivers/net/tun.c:1636 tungetuser+0xc12/0x2030 drivers/net/tun.c:1770 tunchrwriteiter+0x71/0x120 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x45d/0x710 fs/readwrite.c:686 ksyswrite+0xa7/0x170 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xa4/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

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

net/sched: schqfq: do not free existing class in qfqchangeclass()

Fixes qfqchangeclass() error case.

cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.

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

nfsd: provide locking for v4endgrace

Writing to v4endgrace can race with server shutdown and result in memory being accessed after it was freed - reclaimstrhashtbl in particularly.

We cannot hold nfsdmutex across the nfsd4endgrace() call as that is held while clienttrackingop->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4endgrace, resulting in a deadlock.

nfsd4endgrace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4endgrace() might access.

However, we must be sure that writing to v4endgrace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->clientlock. It is set only while it is safe to make client tracking calls, and v4endgrace only schedules work while the flag is set with the spinlock held.

So this patch adds a nfsdnet field "clienttrackingactive" which is set as described. Another field "graceendforced", is set when v4endgrace is written. After this is set, and providing clienttrackingactive is set, the laundromat is scheduled. This "graceendforced" field bypasses other checks for whether the grace period has finished.

This resolves a race which can result in use-after-free.

btrfs: do not free data reservation in fallback from inline due to -ENOSPC

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

iommu/sva: invalidate stale IOTLB entries for kernel address space

Introduce a new IOMMU interface to flush IOTLB paging cache entries for the CPU kernel address space. This interface is invoked from the x86 architecture code that manages combined user and kernel page tables, specifically before any kernel page table page is freed and reused.

This addresses the main issue with vfree() which is a common occurrence and can be triggered by unprivileged users. While this resolves the primary problem, it doesn't address some extremely rare case related to memory unplug of memory that was present as reserved memory at boot, which cannot be triggered by unprivileged users. The discussion can be found at the link below.

Enable SVA on x86 architecture since the IOMMU can now receive notification to flush the paging cache before freeing the CPU kernel page table pages.

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

crypto: seqiv - Do not use req->iv after cryptoaeadencrypt

As soon as cryptoaeadencrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.

Instead of checking req->iv against info, create a new variable unalignedinfo and use it for that purpose instead.

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

RDMA/core: Check for the presence of LSNLATYPEDGID correctly

The netlink response for RDMANLLSOPIPRESOLVE should always have a LSNLATYPEDGID attribute, it is invalid if it does not.

Use the nl parsing logic properly and call nlaparsedeprecated() to fill the nlattrs array and then directly index that array to get the data for the DGID. Just fail if it is NULL.

Remove the for loop searching for the nla, and squash the validation and parsing into one function.

Fixes an uninitialized read from the stack triggered by userspace if it does not provide the DGID to a kernel initiated RDMANLLSOPIPRESOLVE query.

BUG: KMSAN: uninit-value in hexbytepack include/linux/hex.h:13 [inline] BUG: KMSAN: uninit-value in ip6string+0xef4/0x13a0 lib/vsprintf.c:1490 hexbytepack include/linux/hex.h:13 [inline] ip6string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6addrstring+0x18a/0x3e0 lib/vsprintf.c:1509 ipaddrstring+0x245/0xee0 lib/vsprintf.c:1633 pointer+0xc09/0x1bd0 lib/vsprintf.c:2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintkstore+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintkemit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintkdefault+0x3f/0x50 kernel/printk/printk.c:2465 vprintk+0x36/0x50 kernel/printk/printksafe.c:82 printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ibnlprocessgoodiprsep drivers/infiniband/core/addr.c:128 [inline] ibnlhandleipresresp+0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdmanlrcvmsg drivers/infiniband/core/netlink.c:-1 [inline] rdmanlrcvskb drivers/infiniband/core/netlink.c:239 [inline] rdmanlrcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259 netlinkunicastkernel net/netlink/afnetlink.c:1320 [inline] netlinkunicast+0xf04/0x12b0 net/netlink/afnetlink.c:1346 netlinksendmsg+0x10b3/0x1250 net/netlink/afnetlink.c:1896 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0x333/0x3d0 net/socket.c:729 syssendmsg+0x7e0/0xd80 net/socket.c:2617 syssendmsg+0x271/0x3b0 net/socket.c:2671 syssendmsg+0x1aa/0x300 net/socket.c:2703 compatsyssendmsg net/compat.c:346 [inline] docompatsyssendmsg net/compat.c:353 [inline] secompatsyssendmsg net/compat.c:350 [inline] ia32compatsyssendmsg+0xa4/0x100 net/compat.c:350 ia32syscall+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls32.h:371 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x150 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:3

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

scsi: aic94xx: fix use-after-free in device removal path

The asdpciremove() function fails to synchronize with pending tasklets before freeing the asdha structure, leading to a potential use-after-free vulnerability.

When a device removal is triggered (via hot-unplug or module unload), race condition can occur.

The fix adds taskletkill() before freeing the asdha structure, ensuring all scheduled tasklets complete before cleanup proceeds.

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

NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags

When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag.