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

bnxten: Fix RSS context delete logic

We need to free the corresponding RSS context VNIC in FW everytime an RSS context is deleted in driver. Commit 667ac333dbb7 added a check to delete the VNIC in FW only when netifrunning() is true to help delete RSS contexts with interface down.

Having that condition will make the driver leak VNICs in FW whenever close() happens with active RSS contexts. On the subsequent open(), as part of RSS context restoration, we will end up trying to create extra VNICs for which we did not make any reservation. FW can fail this request, thereby making us lose active RSS contexts.

Suppose an RSS context is deleted already and we try to process a delete request again, then the HWRM functions will check for validity of the request and they simply return if the resource is already freed. So, even for delete-when-down cases, netifrunning() check is not necessary.

Remove the netifrunning() condition check when deleting an RSS context.

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

KVM: SEV: Lock all vCPUs when synchronzing VMSAs for SNP launch finish

Lock all vCPUs when synchronizing and encrypting VMSAs for SNP guests, as allowing userspace to manipulate and/or run a vCPU while its state is being synchronized would at best corrupt vCPU state, and at worst crash the host kernel.

Opportunistically assert that vcpu->mutex is held when synchronizing its VMSA (the SEV-ES path already locks vCPUs).

block: fix integer overflow in BLKSECDISCARD

erofs: handle overlapped pclusters out of crafted images properly

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

mptcp: pm: in-kernel: always mark signal+subflow endp as used

Syzkaller managed to find a combination of actions that was generating this warning:

msk->pm.localaddrused == 0 WARNING: net/mptcp/pmkernel.c:1071 at marksubflowendpavailable net/mptcp/pmkernel.c:1071 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pmkernel.c:1071 at mptcpnlremovesubflowandsignaladdr net/mptcp/pmkernel.c:1103 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pmkernel.c:1071 at mptcppmnldeladdrdoit+0x81d/0x8f0 net/mptcp/pmkernel.c:1210, CPU#1: syz.2.17/961 Modules linked in: CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP: 0010:marksubflowendpavailable net/mptcp/pmkernel.c:1071 [inline] RIP: 0010:mptcpnlremovesubflowandsignaladdr net/mptcp/pmkernel.c:1103 [inline] RIP: 0010:mptcppmnldeladdrdoit+0x81d/0x8f0 net/mptcp/pmkernel.c:1210 Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP: 0018:ffffc90001663880 EFLAGS: 00010293 RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: <TASK> genlfamilyrcvmsgdoit+0x117/0x180 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x16d/0x240 net/netlink/afnetlink.c:2550 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x3e9/0x4c0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x4aa/0x5b0 net/netlink/afnetlink.c:1894 socksendmsgnosec net/socket.c:727 [inline] socksendmsg+0xc9/0xf0 net/socket.c:742 syssendmsg+0x272/0x3b0 net/socket.c:2592 syssendmsg+0x2de/0x320 net/socket.c:2646 syssendmsg net/socket.c:2678 [inline] dosyssendmsg net/socket.c:2683 [inline] sesyssendmsg net/socket.c:2681 [inline] x64syssendmsg+0x110/0x1a0 net/socket.c:2681 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x143/0x440 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f66346f826d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 </TASK>

The actions that caused that seem to be:

- Set the MPTCP subflows limit to 0 - Create an MPTCP endpoint with both the 'signal' and 'subflow' flags - Create a new MPTCP connection from a different address: an ADDADDR linked to the MPTCP endpoint will be sent ('signal' flag), but no subflows is initiated ('subflow' flag) - Remove the MPTCP endpoint

---truncated---

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

net: dsa: improve shutdown sequence

Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there.

The first problem is that lan9303 is unique among DSA drivers in that it calls devgetdrvdata() at "arbitrary runtime" (not probe, not shutdown, not remove):

phystatemachine() -> ... -> dsauserphyread() -> ds->ops->phyread() -> lan9303phyread() -> chip->ops->phyread() -> lan9303mdiophyread() -> devgetdrvdata()

But we never stop the phystatemachine(), so it may continue to run after dsaswitchshutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD.

The second problem is that the way in which we set dp->conduit->dsaptr = NULL; is concurrent with receive packet processing. dsaswitchrcv() checks once whether dev->dsaptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsaptr is dereferenced again and again without NULL checks: dsaconduitfinduser() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid.

Both problems have the common aspect that closing the conduit interface solves them.

In the first case, devclose(conduit) triggers the NETDEVGOINGDOWN event in dsausernetdeviceevent() which closes user ports as well. dsaportdisablert() calls phylinkstop(), which synchronously stops the phylink state machine, and ds->ops->phyread() will thus no longer call into the driver after this point.

In the second case, devclose(conduit) should do this, as per Documentation/networking/driver.rst:

| Quiescence | ---------- | | After the ndostop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands.

So it should be sufficient to ensure that later, when we zeroize conduit->dsaptr, there will be no concurrent dsaswitchrcv() call on this conduit.

The addition of the netifdevicedetach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them.

The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsaswitchshutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsaptr (one which doesn't ensure that the interfaces aren't up).

ext4: fix access to uninitialised lock in fc replay path

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

ethtool: coalesce: cap profile updates at NETDIMPARAMSNUMPROFILES

ethnlupdateprofile() walks the ETHTOOLAPROFILEIRQMODERATION nest list with an index 'i' and writes newprofile[i++] without bounding i. The destination is kmemdup()'d at NETDIMPARAMSNUMPROFILES entries (5), but the Netlink nest count is entirely user-controlled. Netlink policies do not have support for constraining the number of nested entries (or number of multi-attr entries).

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

KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPU

Reject synchronizing vCPU state to its associated VMSA if the vCPU has already been launched, i.e. if the VMSA has already been encrypted. On a host with SNP enabled, accessing guest-private memory generates an RMP #PF and panics the host.

BUG: unable to handle page fault for address: ff1276cbfdf36000 #PF: supervisor write access in kernel mode #PF: errorcode(0x80000003) - RMP violation PGD 5a31801067 P4D 5a31802067 PUD 40ccfb5063 PMD 40e5954063 PTE 80000040fdf36163 SEV-SNP: PFN 0x40fdf36, RMP entry: [0x6010fffffffff001 - 0x000000000000001f] Oops: Oops: 0003 [#1] SMP NOPTI CPU: 33 UID: 0 PID: 996180 Comm: qemu-system-x86 Tainted: G OE Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. PowerEdge R7625/0H1TJT, BIOS 1.5.8 07/21/2023 RIP: 0010:sevessyncvmsa+0x54/0x4c0 [kvmamd] Call Trace: <TASK> snplaunchupdatevmsa+0x19d/0x290 [kvmamd] snplaunchfinish+0xb6/0x380 [kvmamd] sevmemencioctl+0x14e/0x720 [kvmamd] kvmarchvmioctl+0x837/0xcf0 [kvm] kvmvmioctl+0x3fd/0xcc0 [kvm] x64sysioctl+0xa3/0x100 x64syscall+0xfe0/0x2350 dosyscall64+0x81/0x10f0 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7ffff673287d </TASK>

Note, the KVM flaw has been present since commit ad73109ae7ec ("KVM: SVM: Provide support to launch and run an SEV-ES guest"), but has only been actively dangerous for the host since SNP support was added. With SEV-ES, KVM would "just" clobber guest state, which is totally fine from a host kernel perspective since userspace can clobber guest state any time before sevlaunchupdatevmsa().

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

net: ethernet: mtkppe: avoid NULL deref when gmac0 is disabled

If the gmac0 is disabled, the precheck for a valid ingress device will cause a NULL pointer deref and crash the system. This happens because eth->netdev[0] will be NULL but the code will directly try to access netdevops.

Instead of just checking for the first netdevice, it must be checked if any of the mtketh netdevices is matching the netdevops of the ingress device.

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

soc: qcom: pd-mapper: Fix element length in servreglocpfrreqei

It looks element length declared in servreglocpfrreqei for reason not matching servreglocpfrreq's reason field due which we could observe decoding error on PD crash.

qmidecodestringelem: String len 81 >= Max Len 65

Fix this by matching with servreglocpfrreq's reason field.

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

mptcp: pm: in-kernel: always set ID as avail when rm endp

Syzkaller managed to find a combination of actions that was generating this warning:

WARNING: net/mptcp/pmkernel.c:1074 at marksubflowendpavailable net/mptcp/pmkernel.c:1074 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pmkernel.c:1074 at mptcppmnlfullmesh net/mptcp/pmkernel.c:1446 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pmkernel.c:1074 at mptcppmnlsetflagsall net/mptcp/pmkernel.c:1474 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pmkernel.c:1074 at mptcppmnlsetflags+0x5de/0x640 net/mptcp/pmkernel.c:1538, CPU#1: syz.7.48/2535 Modules linked in: CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e676cf5 #17 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:marksubflowendpavailable net/mptcp/pmkernel.c:1074 [inline] RIP: 0010:mptcppmnlfullmesh net/mptcp/pmkernel.c:1446 [inline] RIP: 0010:mptcppmnlsetflagsall net/mptcp/pmkernel.c:1474 [inline] RIP: 0010:mptcppmnlsetflags+0x5de/0x640 net/mptcp/pmkernel.c:1538 Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 89 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 <0f> 0b 90 e9 3d ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89 RSP: 0018:ffffc9001535b820 EFLAGS: 00010287 netdevsim0: tunchrioctl cmd 1074025677 RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7 netdevsim0: linktype set to 823 RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800 FS: 00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000000 netlink: 'syz.3.50': attribute type 5 has an invalid length. CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 netlink: 1232 bytes leftover after parsing attributes in process syz.3.50'. CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0 Call Trace: <TASK> mptcppmsetflags net/mptcp/pmnetlink.c:277 [inline] mptcppmnlsetflagsdoit+0x1d7/0x210 net/mptcp/pmnetlink.c:282 genlfamilyrcvmsgdoit+0x117/0x180 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x16d/0x240 net/netlink/afnetlink.c:2550 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x3e9/0x4c0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x4ab/0x5b0 net/netlink/afnetlink.c:1894 socksendmsgnosec net/socket.c:718 [inline] socksendmsg+0xc9/0xf0 net/socket.c:733 syssendmsg+0x272/0x3b0 net/socket.c:2608 syssendmsg+0x2de/0x320 net/socket.c:2662 syssendmsg net/socket.c:2694 [inline] dosyssendmsg net/socket.c:2699 [inline] sesyssendmsg net/socket.c:2697 [inline] x64syssendmsg+0x110/0x1a0 net/socket.c:2697 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xed/0x360 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fc6adb66f6d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000 ---truncated---

drm/amd/display: Add signal type check for dcn401 getphyd32clksrc

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

RDMA/mlx5: Fix error path fall-through in mlx5ibdevressrqinit()

mlx5ibdevressrqinit() allocates two SRQs, s0 and s1. When ibcreatesrq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERRPTR s1 to devr->s0 and devr->s1.

This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERRPTR as already initialised; users in mlx5ibcreateqp() dereference the freed SRQ or ERRPTR via tomsrq(devr->s0)->msrq.srqn; and mlx5ibdevrescleanup() dereferences the ERRPTR and double-frees s0 on teardown.

Fix by adding the same goto unlock in the s1 failure path.

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

x86/mm/identmap: Use gbpages only where full GB page should be mapped.

When identpudinit() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts.

Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request.

No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.

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

Bluetooth: btintel: bound firmware ID by TLV length

The firmware ID is treated as a NUL-terminated string even though the TLV length is its only boundary. If the value does not contain a NUL terminator, snprintf() can read beyond the received response.

Limit the conversion to the advertised TLV value length.

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

ksmbd: safely drain sessions during logoff

SMB3 multichannel allows requests for one session to run on multiple connections. Wait for all channels bound to a session before freeing shared session objects.

A deferred byte-range lock remains counted as a running request and only wakes when its file closes. Wake blocked locks during the drain without unpublishing or modifying their file objects. Synchronous CANCEL requests must invoke their cancellation callback to wake pending operations, while CHANGENOTIFY completion remains specific to the asynchronous path.

Serialize session teardown with channel registration and previous-session cleanup, and use atomic work-state transitions so LOGOFF, CANCEL, and connection teardown invoke cancellation callbacks only once.

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

Bluetooth: btmtk: validate WMT event SKB length before struct access

btmtkusbhciwmtsync() casts the WMT event response SKB data to struct btmtkhciwmtevt (7 bytes) and struct btmtkhciwmtevtfuncc (9 bytes) without first checking that the SKB contains enough data. A short firmware response causes out-of-bounds reads from SKB tailroom.

Use skbpulldata() to validate and advance past the base WMT event header. For the FUNCCTRL case, pull the additional status field bytes before accessing them.

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

iommufd: Break the loop on failure in iommufdfaultfopsread()

On a copytouser() failure inside the inner listforeachentry, only the inner loop breaks; the outer while re-fetches the just-restored fault group and retries the failing copytouser() forever, spinning the reader at 100% CPU with fault->mutex held.

Check rc after the inner loop and break the outer while as well.

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

netfs: Fix zeropoint update where isize > remoteisize

Fix the update of the zero point[] by netfsreleasefolio() when there is uncommitted data in the pagecache beyond the folio being released but the on-server EOF is in this folio (ie. isize > remoteisize). The update needs to limit zeropoint to remoteisize, not isize as isize is a local phenomenon reflecting updates made locally to the pagecache, not stuff written to the server. remoteisize tracks the server's isize.

[] The zero point is the file position from which we can assume that the server will just return zeros, so we can avoid generating reads.

Note that netfsinvalidatefolio() probably doesn't need fixing as zeropoint should be updated by setattr after truncation or fallocate.

Found with:

fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops

using the following as junk.fsxops:

truncate 0x0 0x1bbae 0x82864 write 0x3ef2e 0xf9c8 0x1bbae write 0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copyrange 0x5d3d 0x10329 0x54fac 0x7495f write 0x64710 0x1c2b 0x7495f mapread 0x64000 0x1000 0x7495f

on cifs with the default cache option.

It shows read-gaps on folio 0x64 failing with a short read (ie. it hits EOF) if the FMODEREAD check is commented out in netfsperformwrite():

if (//(file->fmode & FMODEREAD) || netfsiscacheenabled(ctx)) {

and no fscache. This was initially found with the generic/522 xfstest.

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

netfs: Fix partial invalidation of streaming-write folio

In netfsinvalidatefolio(), if the region of a partial invalidation overlaps the front (but not all) of a dirty write cached in a streaming write page (dirty, but not uptodate, with the dirty region tracked by a netfsfolio struct), the function modifies the dirty region - but incorrectly as it moves the region forward by setting the start to the start, not the end, of the invalidation region.

Fix this by setting finfo->dirtyoffset to the end of the invalidation region (iend).

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

pwrseq: core: fix use-after-free in pwrseqdebugfsseqnext()

pwrseqdebugfsseqnext() declares 'next' with free(putdevice), which causes putdevice() to be called on the returned pointer when the variable goes out of scope. This results in a use-after-free since the seqfile framework receives a pointer whose reference has already been dropped.

Simply removing free(putdevice) would fix the UAF but would leak the reference acquired by busfindnextdevice(), as stop() only calls upread(&pwrseqsem) and never releases the device reference.

Fix this by making the reference counting consistent across all seqfile callbacks, matching the standard pattern used by PCI and SCSI:

- start(): use getdevice() so it returns a referenced pointer. - next(): explicitly putdevice(curr) to release the previous device's reference (no NULL check needed - the seqfile framework only calls next() while the previous return was non-NULL). - stop(): putdevice(data) to release the last iterated device's reference, with a NULL guard since stop() may be called with NULL when start() returned NULL or next() reached end-of-sequence.

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

ksmbd: close durable scavenger races against mfplist lookups

ksmbddurablescavenger() has two related races against any walker that iterates fci->mfplist, including ksmbdlookupfdinode() (used by ksmbdvfsrename) and the share-mode checks in fs/smb/server/smbcommon.c.

(1) fp->node list-head reuse. Durable-preserved handles can remain linked on fci->mfplist after session teardown so share-mode checks still see them while the handle is reconnectable. The scavenger collected expired handles by adding fp->node to a local scavengerlist after removing them from the global durable idr. Because fp->node is the same listhead used by mfplist, listadd(&fp->node, &scavengerlist) overwrites the mfplist links and corrupts both lists. CONFIGDEBUGLIST can report this on the share-mode walk path.

(2) Refcount race against mfplist walkers. The scavenger qualifies an expired durable handle with atomicread(&fp->refcount) > 1 and fp->conn under globalft.lock, removes fp from globalft, then drops globalft.lock before unlinking fp from mfplist and freeing it. During that gap fp is still linked on mfplist with fstate == FPINITED. ksmbdlookupfdinode() under mlock read calls ksmbdfpget() (atomicincnotzero on refcount that is still 1) and takes a live reference; the scavenger then unlinks and frees fp while the holder owns a reference, leading to UAF on the holder's subsequent ksmbdfdput() and on any field reads performed by a concurrent share-mode walker that iterates mfplist without taking ksmbdfpget() (smbcheckpermdleases-like paths).

Fix both:

Stop reusing fp->node as a scavenger-private list node. Remove one expired handle from globalft under globalft.lock, take an explicit transient reference, drop the lock, unlink fp->node from mfplist under fci->mlock, then drop both the durable lifetime and transient references with atomicsubandtest(2, &fp->refcount). If the scavenger is the last putter the close runs there; otherwise an in-flight holder that already raced through the mfplist lookup owns the final close via its ksmbdfdput() path. The one-at-a-time disposal can rescan the durable idr when multiple handles expire in the same pass, but durable scavenging is a background expiration path and the final full scan recomputes mintimeout before the next wait.

Clear fp->persistentid inside ksmbdremovedurablefd() right after idrremove(), so a delayed final close from a holder that snatched fp does not re-issue idrremove() on a persistent id that idralloccyclic() in ksmbdopendurablefd() may have already handed out to a brand-new durable handle.

Bypass the per-conn openfilescount decrement in putfdfinal() when fp is detached from any session table (fp->conn cleared by sessionfdcheck() at durable preserve -- paired with the volatileid clear at unpublish, so checking fp->conn alone is sufficient). The walker that owns the final close runs from an unrelated work->conn whose stats.openfilescount never tracked this durable fp; without this guard the holder would underflow that unrelated counter.

The two races are folded into one patch because patch (1) alone cleans up the corrupted list but leaves a deterministic UAF window for mfplist walkers that the transient-reference and persistentid discipline in (2) close; bisecting onto an intermediate state would land on a UAF that pre-patch chaos merely made less reproducible.

Validation: CONFIGDEBUGLIST coverage for the listhead reuse path. KASAN-enabled direct SMB2 durable-handle coverage that exercised ksmbddurablescavenger() and non-NULL ksmbdlookupfdinode() returns while durable handles expired under concurrent rename lookups, with no KASAN, UAF, list-corruption, ODEBUG, or WARNING reports. ---truncated---

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

block: don't overwrite bipvcnt in biointegritycopyuser()

biointegrityaddpage() already sets bipvcnt to 1 for the bounce segment. Overwriting it with nrvecs breaks bipvcnt <= bipmaxvcnt on WRITE (bipmaxvcnt is 1), so the gap-merge checks in block/blk.h read past the bipvec[] flex array. On READ the read is in bounds but lands on a saved user bvec instead of the bounce.

The line was added for split propagation, but biointegrityclone() doesn't copy bipvcnt and BIPCLONEFLAGS excludes BIPCOPYUSER.

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

ethtool: cmis: validate startcmdpayloadsize from module

The CMIS firmware update code reads startcmdpayloadsize from the module's FW Management Features CDB reply and uses it directly as the byte count for memcpy. The destination buffer is 112 bytes (ETHTOOLCMISCDBLPLMAXPLLENGTH - 8). So a malicious module (or corrupted response) can cause a OOB write later on in cmisfwupdatestartdownload().

Let's error out. If modules that expect longer LPL writes actually exist we should revisit.

struct cmiscdbstartfwdownloadpl's definition has to move, no change there.

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

ethtool: module: call ethnlopscomplete() on module flash errors

When validate() fails we are skipping over ethnlopscomplete() even tho we already called ethnlopsbegin().

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

ethtool: cmis: require exact CDB reply length

Malicious SFP module could respond with rpllen longer than what cmiscdbprocessreply() expected, leading to OOB writes. Malicious HW is a bit theoretical but some modules may just be buggy and/or the reads may occasionally get corrupted, so let's protect the kernel.

The existing check protects from short replies. We need to protect from long ones, too. All callers that pass a non-zero rplexplen cast the reply payload to a fixed-layout struct and read fields at fixed offsets, with no version negotiation or short-reply handling:

- cmiscdbvalidatepassword() - cmiscdbmodulefeaturesget() - cmisfwupdatefwmngfeaturesget()

so let's assume that responses longer than expected do not have to be handled gracefully here. Add a warning message to make the debug easier in case my understanding is wrong...

Note that pagedata->length (argument of kmalloc) comes from last arg to ethtoolcmispageinit() which is rplexplen.

Note2 that AIs also like to point out overflows in args->req.payload itself (which is a fixed-size 120 B buffer, on the stack), but callers should be reading structs defined by the standard, so protecting from requests for more data than max seem like defensive programming.

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

iio: adc: mt6359: fix unchecked return value in mt6358readimp

In mt6358readimp(), the variable valv is passed to regmapread() but the return value is not checked. If the read fails, valv remains uninitialized and its random stack content is subsequently reported as a measurement result.

Initialize valv to zero to ensure a predictable value is reported in case of bus failure and to prevent potential stack data leakage. This also satisfies static analyzers that might otherwise flag the variable as used uninitialized.

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

KVM: arm64: Correctly cap ZCREL2 provided by a guest hypervisor

ZCREL2 can be updated by a VHE guest hypervisor either using ZCREL2 (which traps) or ZCREL1 (which does not trap). KVM handles both in different way:

- on ZCREL2 trap, ZCREL2.LEN is immediately capped at the VM's own VL limit. This has the potential to break existing SW that relies on the full LEN field to be stateful.

- on ZCREL1 access, we do absolutely nothing.

On restoring the SVE context for an L2 guest, we directly restore the guest hypervisor's view of ZCREL2 into the physical ZCREL2. If the guest's view of the register was updated using the ZCREL2 accessor, the value has already been sanitised (with the caveat mentioned above).

But if the guest used ZCREL1, the raw value is written into the HW, and the L2 guest can now access VLs that it shouldn't.

Fix all the above by moving the VL capping to the restore points, ensuring that:

- the HW is always programmed with a capped value, irrespective of the accessor being used,

- the ZCREL2.LEN field is always completely stateful, irrespective of the accessor being used.

Additionally, move ZCREL2 to be a sanitised register, ensuring that only the LEN field is actually stateful. This requires some creative construction of the RES0 mask, as the sysreg generation script does not yet generate RAZ/WI fields.

[maz: rewrote commit message, tidy up accesszcrel2()]

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

KVM: SEV: Compute the correct max length of the in-GHCB scratch area

When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer.

The code was "fine" when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the max size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert).

Opportunistically rename @len => @minlen to better reflect its role.