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 <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 ]---
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
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:
RDMA/iwcm: Fix WARNING:atkernel/workqueue.c:#checkflushdependency
In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), the function flushworkqueue is invoked to flush the work queue iwcmwq.
But at that time, the work queue iwcmwq was created via the function allocorderedworkqueue without the flag WQMEMRECLAIM.
Because the current process is trying to flush the whole iwcmwq, if iwcmwq doesn't have the flag WQMEMRECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQMEMRECLAIM as that can break forward-progress guarantee leading to a deadlock.
The call trace is as below:
[ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] <TASK> [ 125.361285][ T1430] ? warn (kernel/panic.c:693) [ 125.367640][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? reportbug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handlebug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? excinvalidop (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asmexcinvalidop (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] flushworkqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? pfxmightresched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroycmid (drivers/infiniband/core/iwcm.c:375) iwcm [ 125.441209][ T1430] ? pfxflushworkqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? rawspinlockirqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlockapismp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? pfxrawspinlockirqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] destroyid (drivers/infiniband/core/cma.c:2044) rdmacm [ 125.495072][ T1430] nvmerdmafreequeue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvmerdma [ 125.505827][ T1430] nvmerdmaresetctrlwork (drivers/nvme/host/rdma.c:2180) nvmerdma [ 125.505831][ T1430] processonework (kernel/workqueue.c:3231) [ 125.515122][ T1430] workerthread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? pfxworkerthread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? pfxkthread (kernel/kthread.c:342) [ 125.550628][ T1430] retfromfork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? pfxkthread (kernel/kthread.c:342) [ 125.558844][ T1430] retfromforkasm (arch/x86/entry/entry64.S:257) [ 125.566487][ T1430] </TASK> [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid OOB when system.data xattr changes underneath the filesystem
When looking up for an entry in an inlined directory, if evalueoffs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF.
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4searchdir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103
CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 ext4searchdir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4findinlineentry+0x4be/0x5e0 fs/ext4/inline.c:1697 ext4findentry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4lookupentry fs/ext4/namei.c:1727 [inline] ext4lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookuponeqstrexcl+0x11f/0x260 fs/namei.c:1633 filenamecreate+0x297/0x540 fs/namei.c:3980 dosymlinkat+0xf9/0x3a0 fs/namei.c:4587 dosyssymlinkat fs/namei.c:4610 [inline] sesyssymlinkat fs/namei.c:4607 [inline] x64syssymlinkat+0x95/0xb0 fs/namei.c:4607 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIGRAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 </TASK>
Calling ext4xattribodyfind right after reading the inode with ext4getinodeloc will lead to a check of the validity of the xattrs, avoiding this problem.
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.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid use-after-free in f2fsstopgcthread()
syzbot reports a f2fs bug as below:
dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printreport+0xe8/0x550 mm/kasan/report.c:491 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicfetchaddrelaxed include/linux/atomic/atomic-instrumented.h:252 [inline] refcountadd include/linux/refcount.h:184 [inline] refcountinc include/linux/refcount.h:241 [inline] refcountinc include/linux/refcount.h:258 [inline] gettaskstruct include/linux/sched/task.h:118 [inline] kthreadstop+0xca/0x630 kernel/kthread.c:704 f2fsstopgcthread+0x65/0xb0 fs/f2fs/gc.c:210 f2fsdoshutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fsiocshutdown fs/f2fs/file.c:2325 [inline] f2fsioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 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
The root cause is below race condition, it may cause use-after-free issue in sbi->gcth pointer.
- remount - f2fsremount - f2fsstopgcthread - kfree(gcth) - f2fsiocshutdown - f2fsdoshutdown - f2fsstopgcthread - kthreadstop(gcth->f2fsgctask) : sbi->gcthread = NULL;
We will call f2fsdoshutdown() in two paths: - for f2fsiocshutdown() path, we should grab sb->sumount semaphore for fixing. - for f2fsshutdown() path, it's safe since caller has already grabbed sb->sumount semaphore.
In the Linux kernel, the following vulnerability has been resolved:
vfs: fix race between eviceinodes() and findinode()&iput()
Hi, all
Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs.
Let's assume there's a inode (ie ino 261) with icount 1 is called by iput(), and there's a concurrent thread calling genericshutdownsuper().
cpu0: cpu1: iput() // icount is 1 ->spinlock(inode) ->dec icount to 0 ->iputfinal() genericshutdownsuper() ->inodeaddlru() ->evictinodes() // cause some reason[2] ->if (atomicread(inode->icount)) continue; // return before // inode 261 passed the above check // listlruaddobj() // and then schedule out ->spinunlock() // note here: the inode 261 // was still at sb list and hash list, // and IFREEING|IWILLFREE was not been set
btrfsiget() // after some function calls ->findinode() // found the above inode 261 ->spinlock(inode) // check IFREEING|IWILLFREE // and passed ->iget() ->spinunlock(inode) // schedule back ->spinlock(inode) // check (INEW|IFREEING|IWILLFREE) flags, // passed and set IFREEING iput() ->spinunlock(inode) ->spinlock(inode) ->evict() // dec icount to 0 ->iputfinal() ->spinunlock() ->evict()
Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->istate & ICLEAR) statement both within clearinode() and iput().
To fix the bug, recheck the inode->icount after holding ilock. Because in the most scenarios, the first check is valid, and the overhead of spinlock() can be reduced.
If there is any misunderstanding, please let me know, thanks.
[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SBACTIVE was removed or 2. mappingshrinkable() return false when I reproduced the bug.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: always wait for both firmware loading attempts
In 'rtwwaitfirmwarecompletion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtwusbintfinit()' has failed in 'rtwusbprobe()', 'rtwusbdisconnect()' may issue 'ieee80211freehw()' when one of 'rtwloadfirmwarecb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.