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:
netfilter: nfrejectipv6: fix nfrejectip6tcphdrput()
syzbot reported that nfrejectip6tcphdrput() was possibly sending garbage on the four reserved tcp bits (th->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:
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.
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.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Use READONCE() when reading entries/indices from PSC buffer
Use READONCE() when reading entries/indices from the guest-accessible Page State Change buffer to defend against TOCTOU bugs.
Don't bother with READONCE()/WRITEONCE() for cases where KVM is writing (and not consuming the result!), as the guest isn't supposed to touch the buffer while it's being processed. I.e. using READONCE() is all about protecting against misbehaving guests.
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: 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 <0f> 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: <TASK> ? 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 </TASK> 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 ]---
Bluetooth: L2CAP: Fix uaf in l2capconnect
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:
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")
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:
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:
bpf: Preserve id of register in synclinkedregs()
synclinkedregs() copies the id of knownreg to reg when propagating bounds of knownreg to reg using the off of knownreg, but when knownreg was linked to reg like:
knownreg = reg ; both knownreg and reg get same id knownreg += 4 ; knownreg gets off = 4, and its id gets BPFADDCONST
now when a call to synclinkedregs() happens, let's say with the following:
if knownreg >= 10 goto pc+2
knownreg's new bounds are propagated to reg but now reg gets BPFADDCONST from the copy.
This means if another link to reg is created like:
anotherreg = reg ; anotherreg should get the id of reg but assignscalaridbeforemov() sees BPFADDCONST on reg and assigns a new id to it.
As reg has a new id now, knownreg's link to reg is broken. If we find new bounds for knownreg, they will not be propagated to reg.
This can be seen in the selftest added in the next commit:
0: (85) call bpfgetprandomu32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,varoff=(0x0; 0x1ff)) 4: (a5) if r1 < 0xa goto pc+4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=10,smax=umax=smax32=umax32=259,varoff=(0x0; 0x1ff)) 5: (bf) r2 = r0 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) R2=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) 6: (a5) if r1 < 0xe goto pc+2 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=14,smax=umax=smax32=umax32=259,varoff=(0x0; 0x1ff)) 7: (35) if r0 >= 0xa goto pc+1 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,varoff=(0x0; 0xf)) 8: (37) r0 /= 0 div by zero
When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPFADDCONST (bug). When 5 is verified, r0 gets a new id (2) and its link with r1 is broken.
After 6 we know r1 has bounds [14, 259] and therefore r0 should have bounds [10, 255], therefore the branch at 7 is always taken. But because r0's id was changed to 2, r1's new bounds are not propagated to r0. The verifier still thinks r0 has bounds [6, 255] before 7 and execution can reach div by zero.
Fix this by preserving id in synclinkedregs() like off and subregdef.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Enforce regsafe base id consistency for BPFADDCONST scalars
When regsafe() compares two scalar registers that both carry BPFADDCONST, checkscalarids() maps their full compound id (aka base | BPFADDCONST flag) as one idmap entry. However, it never verifies that the underlying base ids, that is, with the flag stripped are consistent with existing idmap mappings.
This allows construction of two verifier states where the old state has R3 = R2 + 10 (both sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries: A->B (for R2) and A|flag->C|flag (for R3), without catching that A->C conflicts with A->B. State pruning then incorrectly succeeds.
Fix this by additionally verifying base ID mapping consistency whenever BPFADDCONST is set: after mapping the compound ids, also invoke checkids() on the base IDs (flag bits stripped). This ensures that if A was already mapped to B from comparing the source register, any ADDCONST derivative must also derive from B, not an unrelated C.
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:
HID: bpf: prevent buffer overflow in hidhwrequest
right now the returned value is considered to be always valid. However, when playing with HID-BPF, the return value can be arbitrary big, because it's the return value of dispatchhidbpfrawrequests(), which calls the structops and we have no guarantees that the value makes sense.
In the Linux kernel, the following vulnerability has been resolved:
tcp: check skb is non-NULL in tcprtodeltaus()
We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcprearmrto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases:
Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: errorcode(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? showregs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? nocontext+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6protocoldeliverrcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6sublistrcvfinish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? badareanosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? badareanosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? douseraddrfault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6listrcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? dopagefault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? dopagefault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? pagefault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcpsendlossprobe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcpwritetimerhandler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcpwritetimer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcpwritetimerhandler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] calltimerfn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] runtimers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibratecpukhz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? nativex2apicicrwrite+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapicnexteven ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
nfsd: call cacheput if xdrreservespace returns NULL
If not enough buffer space available, but idmaplookup has triggered lookupfn which calls cacheget and returns successfully. Then we missed to call cacheput here which pairs with cacheget.
Reviwed-by: Jeff Layton <jlayton@kernel.org>
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: fix ARM64 alignment fault in multipath hash seed
struct sysctlfibmultipathhashseed contains two u32 fields (userseed and mpseed), making it an 8-byte structure with a 4-byte alignment requirement.
In fibmultipathhashfromkeys(), the code evaluates the entire struct atomically via READONCE():
mpseed = READONCE(net->ipv4.sysctlfibmultipathhashseed).mpseed;
While this silently works on GCC by falling back to unaligned regular loads which the ARM64 kernel tolerates, it causes a fatal kernel panic when compiled with Clang and LTO enabled.
Commit e35123d83ee3 ("arm64: lto: Strengthen READONCE() to acquire when CONFIGLTO=y") strengthens READONCE() to use Load-Acquire instructions (ldar / ldapr) to prevent compiler reordering bugs under Clang LTO. Since the macro evaluates the full 8-byte struct, Clang emits a 64-bit ldar instruction. ARM64 architecture strictly requires ldar to be naturally aligned, thus executing it on a 4-byte aligned address triggers a strict Alignment Fault (FSC = 0x21).
Fix the read side by moving the READONCE() directly to the u32 member, which emits a safe 32-bit ldar Wn.
Furthermore, Eric Dumazet pointed out that WRITEONCE() on the entire struct in procfibmultipathhashsetseed() is also flawed. Analysis shows that Clang splits this 8-byte write into two separate 32-bit str instructions. While this avoids an alignment fault, it destroys atomicity and exposes a tear-write vulnerability. Fix this by explicitly splitting the write into two 32-bit WRITEONCE() operations.
Finally, add the missing READONCE() when reading userseed in procfibmultipathhashseed() to ensure proper pairing and concurrency safety.
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
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway
Syzbot reports a UAF in hugetlbfault(). This happens because vmfanonprepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlbvmaunlockread() is called.
We can fix this by using a modified version of vmfanonprepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlbvmaunlockread().
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Protect against overflow of ALIGN() during iova allocation
Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIGIOMMUFDTEST can detect this:
WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/iopagetable.c:268 ioptallocareapages drivers/iommu/iommufd/iopagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/iopagetable.c:268 ioptmappages+0xf95/0x1050 drivers/iommu/iommufd/iopagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:ioptallocareapages drivers/iommu/iommufd/iopagetable.c:268 [inline] RIP: 0010:ioptmappages+0xf95/0x1050 drivers/iommu/iommufd/iopagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> iommufdioascopy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufdfopsioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:907 [inline] sesysioctl+0xfc/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix use-after-free in bpfuprobemultilinkattach()
If bpflinkprime() fails, bpfuprobemultilinkattach() goes to the errorfree label and frees the array of bpfuprobe's without calling bpfuprobeunregister().
This leaks bpfuprobe->uprobe and worse, this frees bpfuprobe->consumer without removing it from the uprobe->consumers list.
In the Linux kernel, the following vulnerability has been resolved:
drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error
Ensure index in rtl2830pidfilter does not exceed 31 to prevent out-of-bounds access.
dev->filters is a 32-bit value, so setbit and clearbit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.