In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix incorrect pruning due to atomic fetch precision tracking
Bluetooth: MGMT: Fix UAF on mgmtremoveadvmonitorcomplete
In the Linux kernel, the following vulnerability has been resolved:
NTB: epf: Avoid calling pciirqvector() from hardirq context
ntbepfvecisr() calls pciirqvector() in hardirq context to derive the vector number. pciirqvector() calls msigetvirq() that takes a mutex and can therefore trigger "scheduling while atomic" splats:
BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedulepreemptdisabled+0x28/0x50 mutexlock.constprop.0+0x848/0x908 mutexlockslowpath+0x18/0x30 mutexlock+0x4c/0x60 msidomaingetvirq+0xe8/0x138 pciirqvector+0x2c/0x60 ntbepfvecisr+0x28/0x120 [ntbhwepf] handleirqeventpercpu+0x70/0x3a8 handleirqevent+0x48/0x100 handleedgeirq+0x100/0x1c8 ...
Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.
An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability.
In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: Fix use after free in atomispalloccssstatbufs()
The "s3abuf" is freed along with all the other items on the "asd->s3astats" list. It leads to a double free and a use after free.
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix reconnection fail due to reserved tag allocation
The Linux kernel CVE team has assigned CVE-2024-27435 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051710-CVE-2024-27435-c465@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
mm: do file ownership checks with the proper mount idmap
Ever since idmapped mounts were introduced, inode ownership checks (for side-channel protection) in mincore() and madvise(MADVPAGEOUT) were done against the nopmntidmap, which completely ignores the file's mount's idmap. This results in odd edgecases like:
1) mount/bind-mount with an idmap userA:userB:1 2) userB runs an ownerorcapable() check on file that is owned by userA on-disk/in-memory, but owned by userB after idmap translation 3) ownerorcapable() mysteriously fails as the correct idmap wasn't supplied
In the case of mincore/madvise MADVPAGEOUT, this is usually benign, because filepermission(file, MAYWRITE) will probably succeed, as it uses the proper idmap internally, but it does not need to be the case on e.g a 0444 file where even the owner itself doesn't have permissions to write to it.
Since this is clearly not trivial to get right, introduce a fileownerorcapable() that can carry the correct semantics, and switch the various users in mm to it.
The issue was found by manual code inspection & an off-list discussion with Jan Kara.
In the Linux kernel, the following vulnerability has been resolved:
mtd: require write permissions for locking and badblock ioctls
MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once.
MEMSETBADBLOCK modifies the bad block table.
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level
When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, before querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpageinfo (which typically manifests as a host #PF because the lpageinfo is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot.
When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage.
But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds.
BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmustresstest Not tainted 7.1.0-rc1-48ce1e26eace-x86pirtoirrcomments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvmmmumaxmappinglevel+0x79/0x2b0 [kvm] Call Trace: <TASK> kvmmmurecoverhugepages+0x21b/0x320 [kvm] kvmsetmemslot+0x1ee/0x590 [kvm] kvmsetmemoryregion.part.0+0x3a1/0x4d0 [kvm] kvmvmioctl+0x9bf/0x15d0 [kvm] x64sysioctl+0x8a/0xd0 dosyscall64+0xb7/0xbb0 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK>
Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVMPAGESPERHPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvmmmumaxmappinglevel() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.
A use-after-free flaw was found in hcisendacl in the bluetooth host controller interface (HCI) in Linux kernel, where a local attacker with an access rights could cause a denial of service problem on the system The issue results from the object hchan, freed in hcidisconnloglinkcompleteevt, yet still used in other places. The highest threat from this vulnerability is to data integrity, confidentiality and system availability.
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix use-after free in init error and remove paths
devmblkcryptoprofileinit() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufshba's data structure 'struct ufshba::cryptoprofile'. This structure is allocated as part of the underlying ufshcd and therefore Scsihost allocation.
During driver release or during error handling in ufshcdpltfrminit(), this structure is released as part of ufshcddeallochost() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufshba::cryptoprofile'. This causes a use-after-free situation:
Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blkcryptoprofiledestroycallback+0x28/0x70 devmactionrelease+0x1c/0x30 releasenodes+0x6c/0x108 devresreleaseall+0x98/0x100 deviceunbindcleanup+0x20/0x70 reallyprobe+0x218/0x2d0
In other words, the initialisation code flow is:
platform-device probe ufshcdpltfrminit() ufshcdallochost() scsihostalloc() allocation of struct ufshba creation of scsi-host devices devmblkcryptoprofileinit() devm registration of cleanup handler using platform-device
and during error handling of ufshcdpltfrminit() or during driver removal:
ufshcddeallochost() scsihostput() putdevice(scsi-host) release of struct ufshba putdevice(platform-device) crypto cleanup handler
To fix this use-after free, change ufshcdallochost() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcddeallochost(). This way:
the crypto profile and all other ufshba-owned resources are destroyed before SCSI (as they've been registered after) a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect EXPORTSYMBOLGPL(ufshcddeallochost) can be removed fully as it's not needed anymore no future drivers using ufshcdallochost() could ever forget adding the cleanup
drm/vkms: Fix use after free and double free on init error
In the Linux kernel, the following vulnerability has been resolved:
riscv: uprobes: Add missing fence.i after building the XOL buffer
The XOL (execute out-of-line) buffer is used to single-step the replaced instruction(s) for uprobes. The RISC-V port was missing a proper fence.i (i$ flushing) after constructing the XOL buffer, which can result in incorrect execution of stale/broken instructions.
This was found running the BPF selftests "testprogs: uprobeautoattach, attachprobe" on the Spacemit K1/X60, where the uprobes tests randomly blew up.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix UBSAN shift-out-of-bounds warning
If getnumsdmaqueues or getnumxgmisdmaqueues is 0, we end up doing a shift operation where the number of bits shifted equals number of bits in the operand. This behaviour is undefined.
Set numsdmaqueues or numxgmisdmaqueues to ULLONGMAX, if the count is >= number of bits in the operand.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472
In the Linux kernel, the following vulnerability has been resolved:
smb: client: validate the whole DACL before rewriting it in cifsacl
buildsecdesc() and idmodetocifsacl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor.
The original fix only checked that the struct smbacl header fits before reading daclptr->size or daclptr->numaces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->numaces with no structural validation of the incoming DACL body.
A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replacesidsandcopyaces() or setchmoddacl() past the validated extent while they compare or copy attacker-controlled ACEs.
Factor the DACL structural checks into validatedacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parsedacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Fix crash during unbind if gpio unit is in use
We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device.
If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled.
If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS.
We cannot use the function devmrequestthreadedirq here. The devm clean functions may be called after the main structure is released by uvcdelete.
Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.
In the Linux kernel, the following vulnerability has been resolved:
net: do not leave a dangling sk pointer, when socket creation fails
It is possible to trigger a use-after-free by: attaching an fentry probe to sockrelease() and the probe calling the bpfgetsocketcookie() helper running traceroute -I 1.1.1.1 on a freshly booted VM
A KASAN enabled kernel will log something like below (decoded and stripped): ================================================================== BUG: KASAN: slab-use-after-free in sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299
CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: dumpstacklvl (lib/dumpstack.c:117 (discriminator 1)) printreport (mm/kasan/report.c:378 mm/kasan/report.c:488) ? sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasanreport (mm/kasan/report.c:603) ? sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasancheckrange (mm/kasan/generic.c:183 mm/kasan/generic.c:189) sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) bpfgetsocketptrcookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sockdiag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpfprog875642cf11f1d139sockrelease+0x6e/0x8e bpftrampoline6442506592+0x47/0xaf sockrelease (net/socket.c:652) sockcreate (net/socket.c:1601) ... Allocated by task 299 on cpu 2 at 78.328492s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasanslaballoc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmemcacheallocnoprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) skprotalloc (net/core/sock.c:2075) skalloc (net/core/sock.c:2134) inetcreate (net/ipv4/afinet.c:327 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1572) syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)
Freed by task 299 on cpu 2 at 78.328502s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasansavefreeinfo (mm/kasan/generic.c:582) poisonslabobject (mm/kasan/common.c:242) kasanslabfree (mm/kasan/common.c:256) kmemcachefree (mm/slub.c:4437 mm/slub.c:4511) skdestruct (net/core/sock.c:2117 net/core/sock.c:2208) inetcreate (net/ipv4/afinet.c:397 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1572) syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)
Fix this by clearing the struct socket reference in skcommonrelease() to cover all protocol families create functions, which may already attached the reference to the sk object with sockinitdata().
btrfs: zoned: fix use-after-free due to race with dev replace
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Discard command completions in internal error
Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually.
Kernel log: ------------[ cut here ]------------ refcountt: underflow; use-after-free. ... RIP: 0010:refcountwarnsaturate+0xd8/0xe0 ... Call Trace: <IRQ> ? warn+0x79/0x120 ? refcountwarnsaturate+0xd8/0xe0 ? reportbug+0x17c/0x190 ? handlebug+0x3c/0x60 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0xd8/0xe0 cmdentput+0x13b/0x160 [mlx5core] mlx5cmdcomphandler+0x5f9/0x670 [mlx5core] cmdcompnotifier+0x1f/0x30 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 mlx5eqasyncint+0xf6/0x290 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 irqinthandler+0x19/0x30 [mlx5core] handleirqeventpercpu+0x4b/0x160 handleirqevent+0x2e/0x80 handleedgeirq+0x98/0x230 commoninterrupt+0x3b/0xa0 commoninterrupt+0x7b/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x22/0x40
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: fix info leak when fetching fw build id
Add the missing sanity checks and move the 255-byte build-id buffer off the stack to avoid leaking stack data through debugfs in case the build-info reply is malformed.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: msft: fix slab-use-after-free in msftdoclose()
The Linux kernel CVE team has assigned CVE-2024-36012 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052314-CVE-2024-36012-3062@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
The Linux kernel CVE team has assigned CVE-2024-35789 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051707-CVE-2024-35789-52e5@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
ASoC: lpass: Fix for KASAN useafterfree out of bounds
When we run syzkaller we get below Out of Bounds error.
"KASAN: slab-out-of-bounds Read in regcacheflatread"
Below is the backtrace of the issue:
BUG: KASAN: slab-out-of-bounds in regcacheflatread+0x10c/0x110 Read of size 4 at addr ffffff8088fbf714 by task syz-executor.4/14144 CPU: 6 PID: 14144 Comm: syz-executor.4 Tainted: G W Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT) Call trace: dumpbacktrace+0x0/0x4ec showstack+0x34/0x50 dumpstacklvl+0xdc/0x11c printaddressdescription+0x30/0x2d8 kasanreport+0x178/0x1e4 asanreportload4noabort+0x44/0x50 regcacheflatread+0x10c/0x110 regcacheread+0xf8/0x5a0 regmapread+0x45c/0x86c regmapupdatebits+0x128/0x290 regmapupdatebitsbase+0xc0/0x15c sndsoccomponentupdatebits+0xa8/0x22c sndsoccomponentwritefield+0x68/0xd4 txmacroputdecenum+0x1d0/0x268 sndctlelemwrite+0x288/0x474
By Error checking and checking valid values issue gets rectifies.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix space cache corruption and potential double allocations
When testing spacecache v2 on a large set of machines, we encountered a few symptoms:
1. "unable to add free space :-17" (EEXIST) errors. 2. Missing free space info items, sometimes caught with a "missing free space info for X" error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were marked as allocated twice in the extent tree, or ranges that were marked as free twice in the free space tree. If the latter made it onto disk, the next reboot would hit the BUGON() in addnewfreespace(). 4. On some hosts with no on-disk corruption or error messages, the in-memory space cache (dumped with drgn) disagreed with the free space tree.
All of these symptoms have the same underlying cause: a race between caching the free space for a block group and returning free space to the in-memory space cache for pinned extents causes us to double-add a free range to the space cache. This race exists when free space is cached from the free space tree (spacecache=v2) or the extent tree (nospacecache, or spacecache=v1 if the cache needs to be regenerated). struct btrfsblockgroup::lastbytetounpin and struct btrfsblockgroup::progress are supposed to protect against this race, but commit d0c2f4fa555e ("btrfs: make concurrent fsyncs wait less when waiting for a transaction commit") subtly broke this by allowing multiple transactions to be unpinning extents at the same time.
Specifically, the race is as follows:
1. An extent is deleted from an uncached block group in transaction A. 2. btrfscommittransaction() is called for transaction A. 3. btrfsrundelayedrefs() -> btrfsfreeextent() runs the delayed ref for the deleted extent. 4. btrfsfreeextent() -> dofreeextentaccounting() -> addtofreespacetree() adds the deleted extent back to the free space tree. 5. dofreeextentaccounting() -> btrfsupdateblockgroup() -> btrfscacheblockgroup() queues up the block group to get cached. blockgroup->progress is set to blockgroup->start. 6. btrfscommittransaction() for transaction A calls switchcommitroots(). It sets blockgroup->lastbytetounpin to blockgroup->progress, which is blockgroup->start because the block group hasn't been cached yet. 7. The caching thread gets to our block group. Since the commit roots were already switched, loadfreespacetree() sees the deleted extent as free and adds it to the space cache. It finishes caching and sets blockgroup->progress to U64MAX. 8. btrfscommittransaction() advances transaction A to TRANSSTATESUPERCOMMITTED. 9. fsync calls btrfscommittransaction() for transaction B. Since transaction A is already in TRANSSTATESUPERCOMMITTED and the commit is for fsync, it advances. 10. btrfscommittransaction() for transaction B calls switchcommitroots(). This time, the block group has already been cached, so it sets blockgroup->lastbytetounpin to U64MAX. 11. btrfscommittransaction() for transaction A calls btrfsfinishextentcommit(), which calls unpinextentrange() for the deleted extent. It sees lastbytetounpin set to U64MAX (by transaction B!), so it adds the deleted extent to the space cache again!
This explains all of our symptoms above:
If the sequence of events is exactly as described above, when the free space is re-added in step 11, it will fail with EEXIST. If another thread reallocates the deleted extent in between steps 7 and 11, then step 11 will silently re-add that space to the space cache as free even though it is actually allocated. Then, if that space is allocated again, the free space tree will be corrupted (namely, the wrong item will be deleted). If we don't catch this free space tree corr ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: netlink notifier might race to release objects
commit release path is invoked via callrcu and it runs lockless to release the objects after rcu grace period. The netlink notifier handler might win race to remove objects that the transaction context is still referencing from the commit release path.
Call rcubarrier() to ensure pending rcu callbacks run to completion if the list of transactions to be destroyed is not empty.
In the Linux kernel, the following vulnerability has been resolved:
scsi: ibmvfc: Allocate/free queue resource only during probe/remove
Currently, the sub-queues and event pool resources are allocated/freed for every CRQ connection event such as reset and LPM. This exposes the driver to a couple issues. First the inefficiency of freeing and reallocating memory that can simply be resued after being sanitized. Further, a system under memory pressue runs the risk of allocation failures that could result in a crippled driver. Finally, there is a race window where command submission/compeletion can try to pull/return elements from/to an event pool that is being deleted or already has been deleted due to the lack of host state around freeing/allocating resources. The following is an example of list corruption following a live partition migration (LPM):
Oops: Exception in kernel mode, sig: 5 [#1] LE PAGESIZE=64K MMU=Hash SMP NRCPUS=2048 NUMA pSeries Modules linked in: vfat fat isofs cdrom ext4 mbcache jbd2 nftcounter nftcompat nftables nfnetlink rpadlpario rpaphp xskdiag nfsv3 nfsacl nfs lockd grace fscache netfs rfkill bonding tls sunrpc pseriesrng drm drmpanelorientationquirks xfs libcrc32c dmservicetime sdmod t10pi sg ibmvfc scsitransportfc ibmveth vmxcrypto dmmultipath dmmirror dmregionhash dmlog dmmod ipmidevintf ipmimsghandler fuse CPU: 0 PID: 2108 Comm: ibmvfc0 Kdump: loaded Not tainted 5.14.0-70.9.1.el90.ppc64le #1 NIP: c0000000007c4bb0 LR: c0000000007c4bac CTR: 00000000005b9a10 REGS: c00000025c10b760 TRAP: 0700 Not tainted (5.14.0-70.9.1.el90.ppc64le) MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 2800028f XER: 0000000f CFAR: c0000000001f55bc IRQMASK: 0 GPR00: c0000000007c4bac c00000025c10ba00 c000000002a47c00 000000000000004e GPR04: c0000031e3006f88 c0000031e308bd00 c00000025c10b768 0000000000000027 GPR08: 0000000000000000 c0000031e3009dc0 00000031e0eb0000 0000000000000000 GPR12: c0000031e2ffffa8 c000000002dd0000 c000000000187108 c00000020fcee2c0 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c008000002f81300 GPR24: 5deadbeef0000100 5deadbeef0000122 c000000263ba6910 c00000024cc88000 GPR28: 000000000000003c c0000002430a0000 c0000002430ac300 000000000000c300 NIP [c0000000007c4bb0] listdelentryvalid+0x90/0x100 LR [c0000000007c4bac] listdelentryvalid+0x8c/0x100 Call Trace: [c00000025c10ba00] [c0000000007c4bac] listdelentryvalid+0x8c/0x100 (unreliable) [c00000025c10ba60] [c008000002f42284] ibmvfcfreequeue+0xec/0x210 [ibmvfc] [c00000025c10bb10] [c008000002f4246c] ibmvfcderegisterscsichannel+0xc4/0x160 [ibmvfc] [c00000025c10bba0] [c008000002f42580] ibmvfcreleasesubcrqs+0x78/0x130 [ibmvfc] [c00000025c10bc20] [c008000002f4f6cc] ibmvfcdowork+0x5c4/0xc70 [ibmvfc] [c00000025c10bce0] [c008000002f4fdec] ibmvfcwork+0x74/0x1e8 [ibmvfc] [c00000025c10bda0] [c0000000001872b8] kthread+0x1b8/0x1c0 [c00000025c10be10] [c00000000000cd64] retfromkernelthread+0x5c/0x64 Instruction dump: 40820034 38600001 38210060 4e800020 7c0802a6 7c641b78 3c62fe7a 7d254b78 3863b590 f8010070 4ba309cd 60000000 <0fe00000> 7c0802a6 3c62fe7a 3863b640 ---[ end trace 11a2b65a92f8b66c ]--- ibmvfc 30000003: Send warning. Receive queue closed, will retry.
Add registration/deregistration helpers that are called instead during connection resets to sanitize and reconfigure the queues.
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: don't touch ->tagset in blkmqgetsqhctx
blkmqrunhwqueues() could be run when there isn't queued request and after queue is cleaned up, at that time tagset is freed, because tagset lifetime is covered by driver, and often freed after blkcleanupqueue() returns.
So don't touch ->tagset for figuring out current default hctx by the mapping built in request queue, so use-after-free on tagset can be avoided. Meantime this way should be fast than retrieving mapping from tagset.
In the Linux kernel, the following vulnerability has been resolved:
blktrace: fix use after free for struct blktrace
When tracing the whole disk, 'dropped' and 'msg' will be created under 'q->debugfsdir' and 'bt->dir' is NULL, thus blktracefree() won't remove those files. What's worse, the following UAF can be triggered because of accessing stale 'dropped' and 'msg':
================================================================== BUG: KASAN: use-after-free in blkdroppedread+0x89/0x100 Read of size 4 at addr ffff88816912f3d8 by task blktrace/1188
CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727073836-4 Call Trace: <TASK> dumpstacklvl+0x34/0x44 printaddressdescription.constprop.0.cold+0xab/0x381 ? blkdroppedread+0x89/0x100 ? blkdroppedread+0x89/0x100 kasanreport.cold+0x83/0xdf ? blkdroppedread+0x89/0x100 kasancheckrange+0x140/0x1b0 blkdroppedread+0x89/0x100 ? blkcreatebuffilecallback+0x20/0x20 ? kmemcachefree+0xa1/0x500 ? dosysopenat2+0x258/0x460 fullproxyread+0x8f/0xc0 vfsread+0xc6/0x260 ksysread+0xb9/0x150 ? vfswrite+0x3d0/0x3d0 ? fpregsassertstateconsistent+0x55/0x60 ? exittousermodeprepare+0x39/0x1e0 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7fbc080d92fd Code: ce 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 1 RSP: 002b:00007fbb95ff9cb0 EFLAGS: 00000293 ORIGRAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd RDX: 0000000000000100 RSI: 00007fbb95ff9cc0 RDI: 0000000000000045 RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd R10: 000000000153afa0 R11: 0000000000000293 R12: 00007fbb780008c0 R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8 </TASK>
Allocated by task 1050: kasansavestack+0x1e/0x40 kasankmalloc+0x81/0xa0 doblktracesetup+0xcb/0x410 blktracesetup+0xac/0x130 blktraceioctl+0xe9/0x1c0 blkdevioctl+0xf1/0x390 x64sysioctl+0xa5/0xe0 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x44/0xae
Freed by task 1050: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansetfreeinfo+0x20/0x30 kasanslabfree+0x103/0x180 kfree+0x9a/0x4c0 blktraceremove+0x53/0x70 blktraceioctl+0x199/0x1c0 blkdevcommonioctl+0x5e9/0xb30 blkdevioctl+0x1a5/0x390 x64sysioctl+0xa5/0xe0 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x44/0xae
The buggy address belongs to the object at ffff88816912f380 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 88 bytes inside of 96-byte region [ffff88816912f380, ffff88816912f3e0) The buggy address belongs to the page: page:000000009a1b4e7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0f flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0000200 ffffea00044f1100 dead000000000002 ffff88810004c780 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ==================================================================
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: kms: Clear the HVS FIFO commit pointer once done
Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a wait on the previous commit done on a given HVS FIFO.
However, we never cleared that pointer once done. Since drmcrtccommitput can free the drmcrtccommit structure directly if we were the last user, this means that it can lead to a use-after free if we were to duplicate the state, and that stale pointer would even be copied to the new state.
Set the pointer to NULL once we're done with the wait so that we don't carry over a pointer to a free'd structure.