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

RDMA/rtrs-clt: Reset cid to connum - 1 to stay in bounds

In the function initconns(), after the createcon() and createcm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to cltpath->s.connum.

This commits resets the cid to cltpath->s.connum - 1, to stay in bounds in the cleanup loop later.

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

nbd: fix race between timeout and normal completion

If request timetout is handled by nbdrequeuecmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.

Fix the race by clearing NBDCMDINFLIGHT in nbdrequeuecmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.

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

mptcp: pm: fix UaF read in mptcppmnlrmaddrorsubflow

Syzkaller reported this splat:

================================================================== BUG: KASAN: slab-use-after-free in mptcppmnlrmaddrorsubflow+0xb44/0xcc0 net/mptcp/pmnetlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662

CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 mptcppmnlrmaddrorsubflow+0xb44/0xcc0 net/mptcp/pmnetlink.c:881 mptcppmnlrmsubflowreceived net/mptcp/pmnetlink.c:914 [inline] mptcpnlremoveidzeroaddress+0x305/0x4a0 net/mptcp/pmnetlink.c:1572 mptcppmnldeladdrdoit+0x5c9/0x770 net/mptcp/pmnetlink.c:1603 genlfamilyrcvmsgdoit+0x202/0x2f0 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x565/0x800 net/netlink/genetlink.c:1210 netlinkrcvskb+0x165/0x410 net/netlink/afnetlink.c:2551 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1331 [inline] netlinkunicast+0x53c/0x7f0 net/netlink/afnetlink.c:1357 netlinksendmsg+0x8b8/0xd70 net/netlink/afnetlink.c:1901 socksendmsgnosec net/socket.c:729 [inline] socksendmsg net/socket.c:744 [inline] syssendmsg+0x9ae/0xb40 net/socket.c:2607 syssendmsg+0x135/0x1e0 net/socket.c:2661 syssendmsg+0x117/0x1f0 net/socket.c:2690 dosyscall32irqson arch/x86/entry/common.c:165 [inline] dofastsyscall32+0x73/0x120 arch/x86/entry/common.c:386 dofastsyscall32+0x32/0x80 arch/x86/entry/common.c:411 entrySYSENTERcompatafterhwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIGRAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>

Allocated by task 5387: kasansavestack+0x33/0x60 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmallocnoprof include/linux/slab.h:878 [inline] kzallocnoprof include/linux/slab.h:1014 [inline] subflowcreatectx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflowulpinit+0xc3/0x4d0 net/mptcp/subflow.c:1956 tcpsetulp net/ipv4/tcpulp.c:146 [inline] tcpsetulp+0x326/0x7f0 net/ipv4/tcpulp.c:167 mptcpsubflowcreatesocket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 mptcpsubflowconnect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcppmcreatesubfloworsignaladdr+0xbda/0x23a0 net/mptcp/pmnetlink.c:642 mptcppmnlfullyestablished net/mptcp/pmnetlink.c:650 [inline] mptcppmnlwork+0x3a1/0x4f0 net/mptcp/pmnetlink.c:943 mptcpworker+0x15a/0x1240 net/mptcp/protocol.c:2777 processonework+0x958/0x1b30 kernel/workqueue.c:3229 processscheduledworks kernel/workqueue.c:3310 [inline] workerthread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/ke ---truncated---

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

nvme-fabrics: fix kernel crash while shutting down controller

The nvme keep-alive operation, which executes at a periodic interval, could potentially sneak in while shutting down a fabric controller. This may lead to a race between the fabric controller admin queue destroy code path (invoked while shutting down controller) and hw/hctx queue dispatcher called from the nvme keep-alive async request queuing operation. This race could lead to the kernel crash shown below:

Call Trace: autoremovewakefunction+0x0/0xbc (unreliable) blkmqscheddispatchrequests+0x114/0x24c blkmqscheddispatchrequests+0x44/0x84 blkmqrunhwqueue+0x140/0x220 nvmekeepalivework+0xc8/0x19c [nvmecore] processonework+0x200/0x4e0 workerthread+0x340/0x504 kthread+0x138/0x140 startkernelthread+0x14/0x18

While shutting down fabric controller, if nvme keep-alive request sneaks in then it would be flushed off. The nvmekeepaliveendio function is then invoked to handle the end of the keep-alive operation which decrements the admin->qusagecounter and assuming this is the last/only request in the admin queue then the admin->qusagecounter becomes zero. If that happens then blk-mq destroy queue operation (blkmqdestroy queue()) which could be potentially running simultaneously on another cpu (as this is the controller shutdown code path) would forward progress and deletes the admin queue. So, now from this point onward we are not supposed to access the admin queue resources. However the issue here's that the nvme keep-alive thread running hw/hctx queue dispatch operation hasn't yet finished its work and so it could still potentially access the admin queue resource while the admin queue had been already deleted and that causes the above crash.

The above kernel crash is regression caused due to changes implemented in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()"). Ideally we should stop keep-alive before destroyin g the admin queue and freeing the admin tagset so that it wouldn't sneak in during the shutdown operation. However we removed the keep alive stop operation from the beginning of the controller shutdown code path in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()") and added it under nvmeuninitctrl() which executes very late in the shutdown code path after the admin queue is destroyed and its tagset is removed. So this change created the possibility of keep-alive sneaking in and interfering with the shutdown operation and causing observed kernel crash.

To fix the observed crash, we decided to move nvmestopkeepalive() from nvmeuninitctrl() to nvmeremoveadmintagset(). This change would ensure that we don't forward progress and delete the admin queue until the keep- alive operation is finished (if it's in-flight) or cancelled and that would help contain the race condition explained above and hence avoid the crash.

Moving nvmestopkeepalive() to nvmeremoveadmintagset() instead of adding nvmestopkeepalive() to the beginning of the controller shutdown code path in nvmestopctrl(), as was the case earlier before commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()"), would help save one callsite of nvmestopkeepalive().

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

RDMA/iwcm: Fix workqueue list corruption by removing worklist

The commit e1168f0 ("RDMA/iwcm: Simplify cmeventhandler()") changed the work submission logic to unconditionally call queuework() with the expectation that queuework() would have no effect if work was already pending. The problem is that a free list of struct iwcmwork is used (for which struct workstruct is embedded), so each call to queuework() is basically unique and therefore does indeed queue the work.

This causes a problem in the work handler which walks the worklist until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INITWORK...) and lead to list corruption in the workqueue logic.

Fix this by just removing the worklist. The workqueue already does this for us.

This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode:

[ 151.465780] listdel corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/listdebug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iwcmwq) [ 151.469478] RIP: 0010:listdelentryvalidorreport+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] <TASK> [ 151.476497] movelinkedworks+0x49/0xa0 [ 151.476792] pwqactivatework.isra.46+0x2f/0xa0 [ 151.477151] pwqdecnrinflight+0x1e0/0x2f0 [ 151.477479] processscheduledworks+0x1c8/0x410 [ 151.477823] workerthread+0x125/0x260 [ 151.478108] ? pfxworkerthread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? pfxkthread+0x10/0x10 [ 151.478955] ? pfxkthread+0x10/0x10 [ 151.479240] retfromfork+0x208/0x270 [ 151.479523] ? pfxkthread+0x10/0x10 [ 151.479806] retfromforkasm+0x1a/0x30 [ 151.480103] </TASK>

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

icmp: change the order of rate limits

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

cifs: Fix buffer overflow when parsing NFS reparse points

ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength.

Function cifsstrndupfromutf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len.

Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access.

Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparsemkdev().

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

netfilter: nfrejectipv6: fix nfrejectip6tcphdrput()

syzbot reported that nfrejectip6tcphdrput() was possibly sending garbage on the four reserved tcp bits (th-&gt;res1)

Use skbputzero() to clear the whole TCP header, as done in nfrejectiptcphdrput()

BUG: KMSAN: uninit-value in nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 netifreceiveskbonecore net/core/dev.c:5661 [inline] netifreceiveskb+0x1da/0xa00 net/core/dev.c:5775 processbacklog+0x4ad/0xa50 net/core/dev.c:6108 napipoll+0xe7/0x980 net/core/dev.c:6772 napipoll net/core/dev.c:6841 [inline] netrxaction+0xa5a/0x19b0 net/core/dev.c:6963 handlesoftirqs+0x1ce/0x800 kernel/softirq.c:554 dosoftirq+0x14/0x1a kernel/softirq.c:588 dosoftirq+0x9a/0x100 kernel/softirq.c:455 localbhenableip+0x9f/0xb0 kernel/softirq.c:382 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:908 [inline] devqueuexmit+0x2692/0x5610 net/core/dev.c:4450 devqueuexmit include/linux/netdevice.h:3105 [inline] neighresolveoutput+0x9ca/0xae0 net/core/neighbour.c:1565 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x2347/0x2ba0 net/ipv6/ip6output.c:141 ip6finishoutput net/ipv6/ip6output.c:215 [inline] ip6finishoutput+0xbb8/0x14b0 net/ipv6/ip6output.c:226 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x356/0x620 net/ipv6/ip6output.c:247 dstoutput include/net/dst.h:450 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6xmit+0x1ba6/0x25d0 net/ipv6/ip6output.c:366 inet6cskxmit+0x442/0x530 net/ipv6/inet6connectionsock.c:135 tcptransmitskb+0x3b07/0x4880 net/ipv4/tcpoutput.c:1466 tcptransmitskb net/ipv4/tcpoutput.c:1484 [inline] tcpconnect+0x35b6/0x7130 net/ipv4/tcpoutput.c:4143 tcpv6connect+0x1bcc/0x1e40 net/ipv6/tcpipv6.c:333 inetstreamconnect+0x2ef/0x1730 net/ipv4/afinet.c:679 inetstreamconnect+0x6a/0xd0 net/ipv4/afinet.c:750 sysconnectfile net/socket.c:2061 [inline] sysconnect+0x606/0x690 net/socket.c:2078 dosysconnect net/socket.c:2088 [inline] sesysconnect net/socket.c:2085 [inline] x64sysconnect+0x91/0xe0 net/socket.c:2085 x64syscall+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:43 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was stored to memory at: nfrejectip6tcphdrput+0x60c/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:249 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 netifreceiveskbonecore ---truncated---

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

wifi: rtw89: remove unused C2H event ID RTW89MACC2HFUNCREADWOWCAM to prevent out-of-bounds reading

The handler of firmware C2H event RTW89MACC2HFUNCREADWOWCAM isn't implemented, but driver expects number of handlers is NUMOFRTW89MACC2HFUNCWOW causing out-of-bounds access. Fix it by removing ID.

Addresses-Coverity-ID: 1598775 ("Out-of-bounds read")

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

wifi: ath11k: use work queue to process beacon tx event

Commit 3a415daa3e8b ("wifi: ath11k: add P2P IE in beacon template") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning:

drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11kwmip2pgobcnie() warn: sleeping in atomic context

The reason is that ath11kbcntxstatusevent() will directly call might sleep function ath11kwmicmdsend() during RCU read-side critical sections. The call trace is like:

ath11kbcntxstatusevent() -> rcureadlock() -> ath11kmacbcntxevent() -> ath11kmacsetupbcntmpl() …… -> ath11kwmibcntmpl() -> ath11kwmicmdsend() -> rcureadunlock()

Commit 886433a98425 ("ath11k: add support for BSS color change") added the ath11kmacbcntxevent(), commit 01e782c89108 ("ath11k: fix warning of RCU usage for ath11kmacgetarvifbyvdevid()") added the RCU lock to avoid warning but also introduced this BUG.

Use work queue to avoid directly calling ath11kmacbcntxevent() during RCU critical sections. No need to worry about the deletion of vif because cancelworksync() will drop the work if it doesn't start or block vif deletion until the running work is done.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPLV1V2SILICONZLITE-3.6510.30

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

wifi: ath11k: fix array out-of-bound access in SoC stats

Currently, the ath11ksocdpstats::halreoerror array is defined with a maximum size of DPREODSTRINGMAX. However, the ath11kdpprocessrx() function access ath11ksocdpstats::halreoerror using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11kdpprocessrx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPLSILICONZ-1

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

wifi: rtw89: avoid to add interface to list twice when SER

If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211reconfig(). However, due to rtw89wowresume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list.

listadd double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS GoogleGrunt.11031.169.0 06/24/2021 Workqueue: eventsfreezable ieee80211restartwork [mac80211] RIP: 0010:listaddvalidorreport+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 &lt;0f&gt; 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: &lt;TASK&gt; ? diebody+0x1f/0x70 ? die+0x3d/0x60 ? dotrap+0xa4/0x110 ? listaddvalidorreport+0x5e/0xb0 ? doerrortrap+0x6d/0x90 ? listaddvalidorreport+0x5e/0xb0 ? handleinvalidop+0x30/0x40 ? listaddvalidorreport+0x5e/0xb0 ? excinvalidop+0x3c/0x50 ? asmexcinvalidop+0x16/0x20 ? listaddvalidorreport+0x5e/0xb0 rtw89opsaddinterface+0x309/0x310 [rtw89core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drvaddinterface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finishwait+0x3e/0x90 ? synchronizercuexpedited+0x174/0x260 ? syncrcuexpdoneunlocked+0x50/0x50 ? wakebitfunction+0x40/0x40 ieee80211restartwork+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] processscheduledworks+0x1e5/0x480 workerthread+0xea/0x1e0 kthread+0xdb/0x110 ? movelinkedworks+0x90/0x90 ? kthreadassociateblkcg+0xa0/0xa0 retfromfork+0x3b/0x50 ? kthreadassociateblkcg+0xa0/0xa0 retfromforkasm+0x11/0x20 &lt;/TASK&gt; Modules linked in: dmintegrity asyncxor xor asynctx lz4 lz4compress zstd zstdcompress zram zsmalloc rfcomm cmac uinput algifhash algifskcipher afalg btusb btrtl iiotrighrtimer industrialioswtrigger btmtk industrialioconfigfs btbcm btintel uvcvideo videobuf2vmalloc iiotrigsysfs videobuf2memops videobuf2v4l2 videobuf2common uvc sndhdacodechdmi veth sndhdaintel sndinteldspcfg acpials sndhdacodec industrialiotriggeredbuffer kfifobuf sndhwdep industrialio i2cpiix4 sndhdacore designwarei2s ip6tablenat sndsocmax98357a xtMASQUERADE xtcgroup sndsocacprt5682mach fuse rtw898922ae(O) rtw898922a(O) rtw89pci(O) rtw89core(O) 8021q mac80211(O) bluetooth ecdhgeneric ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---

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

net/xen-netback: prevent UAF in xenvifflushhash()

During the listforeachentryrcu iteration call of xenvifflushhash, kfreercu does not exist inside the rcu read critical section, so if kfreercu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free.

Therefore, to solve this, you need to change it to listforeachentrysafe.

Bluetooth: L2CAP: Fix uaf in l2capconnect

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

aoe: fix the potential use-after-free problem in more places

For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmdcfgpkts") makes tx() calling devput() instead of doing in aoecmdcfgpkts(). It avoids that the tx() runs into use-after-free.

Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmdatarw(), resend(), probe() and aoecmdcfgrsp(). Those functions also use aoenetxmit() to push packet to tx queue. So they should also use devhold() to increase the refcnt of skb->dev.

On the other hand, moving devput() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding devhold() are not called in revalidate(), aoecmdatarw(), resend(), probe(), and aoecmdcfgrsp(). This patch fixed this issue.

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

ksmbd: add refcnt to ksmbdconn struct

When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbdconn struct so that it can be freed when it is no longer used.

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

firewire: core: fix invalid port index for parent device

In a commit 24b7f8e5cd65 ("firewire: core: use helper functions for self ID sequence"), the enumeration over self ID sequence was refactored with some helper functions with KUnit tests. These helper functions are guaranteed to work expectedly by the KUnit tests, however their application includes a mistake to assign invalid value to the index of port connected to parent device.

This bug affects the case that any extra node devices which has three or more ports are connected to 1394 OHCI controller. In the case, the path to update the tree cache could hits WARNON(), and gets general protection fault due to the access to invalid address computed by the invalid value.

This commit fixes the bug to assign correct port index.

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

Bluetooth: hcievent: Align BR/EDR JUSTWORKS paring with LE

This aligned BR/EDR JUSTWORKS method with LE which since 92516cd97fd4 ("Bluetooth: Always request for user confirmation for Just Works") always request user confirmation with confirmhint set since the likes of bluetoothd have dedicated policy around JUSTWORKS method (e.g. main.conf:JustWorksRepairing).

CVE: CVE-2024-8805

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

HID: bpf: abort dispatch if device destroyed

The current HID bpf implementation assumes no output report/request will go through it after hidbpfdestroydevice() has been called. This leads to a bug that unplugging certain types of HID devices causes a cleaned- up SRCU to be accessed. The bug was previously a hidden failure until a recent x86 percpu change [1] made it access not-present pages.

The bug will be triggered if the conditions below are met:

A) a device under the driver has some LEDs on B) hidlldriver->request() is uninplemented (e.g., logitech-djreceiver)

If condition A is met, hidinputledworker() is always scheduled after hidbpfdestroydevice().

hiddestroydevice hidbpfdestroydevice cleanupsrcustruct(&hdev->bpf.srcu) hidremovedevice ... ledclassdevunregister ledtriggerset(ledcdev, NULL) ledsetbrightness(ledcdev, LEDOFF) ... inputinjectevent inputeventdispose hidinputinputevent schedulework(&hid->ledwork) [hidinputledworker]

This is fine when condition B is not met, where hidinputledworker() calls hidlldriver->request(). This is the case for most HID drivers, which implement it or use the generic one from usbhid. The driver itself or an underlying driver will then abort processing the request.

Otherwise, hidinputledworker() tries hidhwoutputreport() and leads to the bug.

hidinputledworker hidhwoutputreport dispatchhidbpfoutputreport srcureadlock(&hdev->bpf.srcu) srcureadunlock(&hdev->bpf.srcu, idx)

The bug has existed since the introduction [2] of dispatchhidbpfoutputreport(). However, the same bug also exists in dispatchhidbpfrawrequests(), and I've reproduced (no visible effect because of the lack of [1], but confirmed bpf.destroyed == 1) the bug against the commit (i.e., the Fixes:) introducing the function. This is because hidinputledworker() falls back to hidhwrawrequest() when hidlldriver->outputreport() is uninplemented (e.g., logitech- djreceiver).

hidinputledworker hidhwoutputreport: -ENOSYS hidhwrawrequest dispatchhidbpfrawrequests srcureadlock(&hdev->bpf.srcu) srcureadunlock(&hdev->bpf.srcu, idx)

Fix the issue by returning early in the two mentioned functions if hidbpf has been marked as destroyed. Though dispatchhidbpfdeviceevent() handles input events, and there is no evidence that it may be called after the destruction, the same check, as a safety net, is also added to it to maintain the consistency among all dispatch functions.

The impact of the bug on other architectures is unclear. Even if it acts as a hidden failure, this is still dangerous because it corrupts whatever is on the address calculated by SRCU. Thus, CC'ing the stable list.

[1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets") [2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for hidhwoutputreport")

HID: multitouch: fix slab out-of-bounds access in mtreportfixup()

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:

KVM: arm64: Reassign nestedmmus array behind mmulock

kvm->arch.nestedmmus[] is walked under kvm->mmulock, including from the MMU notifier path (kvmunmapgfnrange() -> kvmnesteds2unmap()), which can run at any time. kvmvcpuinitnested() reallocates the array and frees the old buffer while holding only kvm->arch.configlock, so such a walker can reference the freed array.

Allocate the new array outside of mmulock, as the allocation can sleep. Under the lock, copy the existing entries, fix up the back pointers and reassign the array. Free the old buffer after dropping the lock, as kvfree() can sleep as well.

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

scsi: sd: Fix off-by-one error in sdreadblockcharacteristics()

Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sdreadblockcharacteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.

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

virtiopci: Fix admin vq cleanup by using correct info pointer

vpmodernavqcleanup() and vpdelvqs() clean up admin vq resources by virtiopcivqinfo pointer. The info pointer of admin vq is stored in vpdev->adminvq.info instead of vpdev->vqs[]. Using the info pointer from vpdev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vpmodernavqcleanup() and vpdelvqs(), get the info pointer from vpdev->adminvq.info for admin vq to clean up the resources. Also make info ptr as argument of vpdelvq() to be symmetric with vpsetupvq().

vpreset calls vpmodernavqcleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vpreset+0x57/0x90 [virtiopci] Call Trace: <TASK> ... ? vpreset+0x57/0x90 [virtiopci] ? vpreset+0x38/0x90 [virtiopci] virtioresetdevice+0x1d/0x30 removevqcommon+0x1c/0x1a0 [virtionet] virtnetremove+0xa1/0xc0 [virtionet] virtiodevremove+0x46/0xa0 ... virtiopcidriverexit+0x14/0x810 [virtiopci] ==================================================================

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

mailbox: mtk-cmdq: fix wrong use of sizeof in cmdqgetclocks()

It should be size of the struct clkbulkdata, not data pointer pass to devmkcalloc().

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

wifi: wilc1000: fix potential RCU dereference issue in wilcparsejoinbssparam

In the wilcparsejoinbssparam function, the TSF field of the ies structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues.

This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues.

To address this, the TSF value is now stored in a local variable iestsf before the RCU lock is released. The param->tsflo field is then assigned using this local variable, ensuring that the TSF value is safely accessed.

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

fs/ntfs3: Initialize new folios before use

KMSAN reports an uninitialized value in longestmatchstd(), invoked from ntfscompresswrite(). When new folios are allocated without being marked uptodate and nireadframe() is skipped because the caller expects the frame to be completely overwritten, some reserved folios may remain only partially filled, leaving the rest memory uninitialized.

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

Bluetooth: btintelpcie: Allocate memory for driver private data

Fix driver not allocating memory for struct btinteldata which is used to store internal data.

bpf: Fail verification for sign-extension of packet data/dataend/datameta