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.
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:
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.
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown
epfntbepcdestroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allowlink fails or when .droplink is performed. Remove the helper.
Also drop pciepcput(). EPC device refcounting is tied to configfs EPC group lifetime, and pciepcput() in the .droplink path is sufficient.
In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq256xx: Fix use-after-free in powersupplychanged()
Using the devm variant for requesting IRQ before the devm variant for allocating/registering the powersupply handle, means that the powersupply handle will be deallocated/unregistered before the interrupt handler (since devm naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just after the powersupply handle has been freed, but just before the corresponding unregistration of the IRQ handler has run.
This will lead to the IRQ handler calling powersupplychanged() with a freed powersupply handle. Which usually crashes the system or otherwise silently corrupts the memory...
Note that there is a similar situation which can also happen during probe(); the possibility of an interrupt firing before registering the powersupply handle. This would then lead to the nasty situation of using the powersupply handle uninitialized in powersupplychanged().
Fix this racy use-after-free by making sure the IRQ is requested after the registration of the powersupply handle.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix incorrect pruning due to atomic fetch precision tracking
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:
RDMA/efa: Fix use of completion ctx after free
On admin queue completion handling, if the admin command completed with error we print data from the completion context. The issue is that we already freed the completion context in polling/interrupts handler which means we print data from context in an unknown state (it might be already used again). Change the admin submission flow so alloc/dealloc of the context will be symmetric and dealloc will be called after any potential use of the context.
In the Linux kernel, the following vulnerability has been resolved:
s390/syscalls: Add spectre boundary for syscall dispatch table
The s390 syscall number is directly controlled by userspace, but does not have an arrayindexnospec() boundary to prevent access past the syscall function pointer tables.
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Avoid creating sub-groups asynchronously
The asynchronous creation of sub-groups by a delayed work could lead to a NULL pointer dereference when the driver directory is removed before the work completes.
The crash can be easily reproduced with the following commands:
# cd /sys/kernel/config/pciep/functions/pciepftest # for i in {1..20}; do mkdir test && rmdir test; done
BUG: kernel NULL pointer dereference, address: 0000000000000088 ... Call Trace: configfsregistergroup+0x3d/0x190 pciepfcfswork+0x41/0x110 processonework+0x18f/0x350 workerthread+0x25a/0x3a0
Fix this issue by using configfsadddefaultgroup() API which does not have the deadlock problem as configfsregistergroup() and does not require the delayed work handler.
[mani: slightly reworded the description and added stable list]
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:
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
Bluetooth: MGMT: Fix UAF on mgmtremoveadvmonitorcomplete
In the Linux kernel, the following vulnerability has been resolved:
btrfs: replace BTRFSMAXEXTENTSIZE with fsinfo->maxextentsize
On zoned filesystem, data write out is limited by maxzoneappendsize, and a large ordered extent is split according the size of a bio. OTOH, the number of extents to be written is calculated using BTRFSMAXEXTENTSIZE, and that estimated number is used to reserve the metadata bytes to update and/or create the metadata items.
The metadata reservation is done at e.g, btrfsbufferedwrite() and then released according to the estimation changes. Thus, if the number of extent increases massively, the reserved metadata can run out.
The increase of the number of extents easily occurs on zoned filesystem if BTRFSMAXEXTENTSIZE > maxzoneappendsize. And, it causes the following warning on a small RAM environment with disabling metadata over-commit (in the following patch).
[75721.498492] ------------[ cut here ]------------ [75721.505624] BTRFS: block rsv 1 returned -28 [75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfsuseblockrsv+0x560/0x760 [btrfs] [75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: loaded Tainted: G W 5.18.0-rc2-BTRFS-ZNS+ #109 [75721.597200] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 [75721.607310] Workqueue: btrfs-endio-write btrfsworkhelper [btrfs] [75721.616209] RIP: 0010:btrfsuseblockrsv+0x560/0x760 [btrfs] [75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286 [75721.654126] RAX: 0000000000000000 RBX: 0000000000004000 RCX: 0000000000000000 [75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e [75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7 [75721.682493] R10: ffffed13f1a3f8d8 R11: 0000000000000001 R12: ffff88980a3c0e28 [75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a [75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000 [75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0 [75721.730499] Call Trace: [75721.735166] <TASK> [75721.739886] btrfsalloctreeblock+0x1e1/0x1100 [btrfs] [75721.747545] ? btrfsallocloggedfileextent+0x550/0x550 [btrfs] [75721.756145] ? btrfsget32+0xea/0x2d0 [btrfs] [75721.762852] ? btrfsget32+0xea/0x2d0 [btrfs] [75721.769520] ? pushleafleft+0x420/0x620 [btrfs] [75721.776431] ? memcpy+0x4e/0x60 [75721.781931] splitleaf+0x433/0x12d0 [btrfs] [75721.788392] ? btrfsgettoken32+0x580/0x580 [btrfs] [75721.795636] ? pushfordoublesplit.isra.0+0x420/0x420 [btrfs] [75721.803759] ? leafspaceused+0x15d/0x1a0 [btrfs] [75721.811156] btrfssearchslot+0x1bc3/0x2790 [btrfs] [75721.818300] ? lockdowngrade+0x7c0/0x7c0 [75721.824411] ? freeextentbuffer.part.0+0x107/0x200 [btrfs] [75721.832456] ? splitleaf+0x12d0/0x12d0 [btrfs] [75721.839149] ? freeextentbuffer.part.0+0x14f/0x200 [btrfs] [75721.846945] ? freeextentbuffer+0x13/0x20 [btrfs] [75721.853960] ? btrfsreleasepath+0x4b/0x190 [btrfs] [75721.861429] btrfscsumfileblocks+0x85c/0x1500 [btrfs] [75721.869313] ? rcureadlockschedheld+0x16/0x80 [75721.876085] ? lockrelease+0x552/0xf80 [75721.881957] ? btrfsdelcsums+0x8c0/0x8c0 [btrfs] [75721.888886] ? kasancheckwrite+0x14/0x20 [75721.895152] ? dorawreadunlock+0x44/0x80 [75721.901323] ? rawwritelockirq+0x60/0x80 [75721.907983] ? btrfsglobalroot+0xb9/0xe0 [btrfs] [75721.915166] ? btrfscsumroot+0x12b/0x180 [btrfs] [75721.921918] ? btrfsgetglobalroot+0x820/0x820 [btrfs] [75721.929166] ? rawwriteunlock+0x23/0x40 [75721.935116] ? unpinextentcache+0x1e3/0x390 [btrfs] [75721.942041] btrfsfinishorderedio.isra.0+0xa0c/0x1dc0 [btrfs] [75721.949906] ? trytowakeup+0x30/0x14a0 [75721.955700] ? btrfsunlinksubvol+0xda0/0xda0 [btrfs] [75721.962661] ? rcu ---truncated---
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:
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:
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:
arm64: entry: avoid kprobe recursion
The cortexa76erratum1463225debughandler() function is called when handling debug exceptions (and synchronous exceptions from BRK instructions), and so is called when a probed function executes. If the compiler does not inline cortexa76erratum1463225debughandler(), it can be probed.
If cortexa76erratum1463225debughandler() is probed, any debug exception or software breakpoint exception will result in recursive exceptions leading to a stack overflow. This can be triggered with the ftrace multipleprobes selftest, and as per the example splat below.
This is a regression caused by commit:
6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround")
... which removed the NOKPROBESYMBOL() annotation associated with the function.
My intent was that cortexa76erratum1463225debughandler() would be inlined into its caller, el1dbg(), which is marked noinstr and cannot be probed. Mark cortexa76erratum1463225debughandler() as alwaysinline to ensure this.
Example splat prior to this patch (with recursive entries elided):
| # echo p cortexa76erratum1463225debughandler > /sys/kernel/debug/tracing/kprobeevents | # echo p doel0svc >> /sys/kernel/debug/tracing/kprobeevents | # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable | Insufficient stack space to handle exception! | ESR: 0x0000000096000047 -- DABT (current EL) | FAR: 0xffff800009cefff0 | Task stack: [0xffff800009cf0000..0xffff800009cf4000] | IRQ stack: [0xffff800008000000..0xffff800008004000] | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0] | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arm64enterel1dbg+0x4/0x20 | lr : el1dbg+0x24/0x5c | sp : ffff800009cf0000 | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068 | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0 | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4 | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040 | Kernel panic - not syncing: kernel stack overflow | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | Call trace: | dumpbacktrace+0xe4/0x104 | showstack+0x18/0x4c | dumpstacklvl+0x64/0x7c | dumpstack+0x18/0x38 | panic+0x14c/0x338 | testtaint+0x0/0x2c | panicbadstack+0x104/0x118 | handlebadstack+0x34/0x48 | badstack+0x78/0x7c | arm64enterel1dbg+0x4/0x20 | el1h64synchandler+0x40/0x98 | el1h64sync+0x64/0x68 | cortexa76erratum1463225debughandler+0x0/0x34 ... | el1h64synchandler+0x40/0x98 | el1h64sync+0x64/0x68 | cortexa76erratum1463225debughandler+0x0/0x34 ... | el1h64synchandler+0x40/0x98 | el1h64sync+0x64/0x68 | cortexa76erratum1463225debughandler+0x0/0x34 | el1h64synchandler+0x40/0x98 | el1h64sync+0x64/0x68 | doel0svc+0x0/0x28 | el0t64synchandler+0x84/0xf0 | el0t64sync+0x18c/0x190 | Kernel Offset: disabled | CPU features: 0x0080,00005021,19001080 | Memory Limit: none | ---[ end Kernel panic - not syncing: kernel stack overflow ]---
With this patch, cortexa76erratum1463225debughandler() is inlined into el1dbg(), and el1dbg() cannot be probed:
| # echo p cortexa76erratum1463225debughandler > /sys/kernel/debug/tracing/kprobeevents | sh: write error: No such file or directory | # grep -w cortexa76errat ---truncated---
drm/vkms: Fix use after free and double free on init error
In the Linux kernel, the following vulnerability has been resolved:
drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmdioctl
In the "pmcmdioctl" function, three memory objects allocated by kmalloc are initialized by "hcallgetcpustate", which are then copied to user space. The initializer is indeed implemented in "acrnhypercall2" (arch/x86/include/asm/acrn.h). There is a risk of information leakage due to uninitialized bytes.
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:
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
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:
ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type
Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: rx-macro: fix accessing compander for aux
AUX interpolator does not have compander, so check before accessing compander data for this.
Without this checkan array of out bounds access will be made in compenabled[] array.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix UAF due to race between btftrygetmodule and loadmodule
While working on code to populate kfunc BTF ID sets for module BTF from its initcall, I noticed that by the time the initcall is invoked, the module BTF can already be seen by userspace (and the BPF verifier). The existing btftrygetmodule calls trymoduleget which only fails if mod->state == MODULESTATEGOING, i.e. it can increment module reference when module initcall is happening in parallel.
Currently, BTF parsing happens from MODULESTATECOMING notifier callback. At this point, the module initcalls have not been invoked. The notifier callback parses and prepares the module BTF, allocates an ID, which publishes it to userspace, and then adds it to the btfmodules list allowing the kernel to invoke btftrygetmodule for the BTF.
However, at this point, the module has not been fully initialized (i.e. its initcalls have not finished). The code in module.c can still fail and free the module, without caring for other users. However, nothing stops btftrygetmodule from succeeding between the state transition from MODULESTATECOMING to MODULESTATELIVE.
This leads to a use-after-free issue when BPF program loads successfully in the state transition, loadmodule's doinitmodule call fails and frees the module, and BPF program fd on close calls moduleput for the freed module. Future patch has test case to verify we don't regress in this area in future.
There are multiple points after preparecomingmodule (in loadmodule) where failure can occur and module loading can return error. We illustrate and test for the race using the last point where it can practically occur (in module init function).
An illustration of the race:
CPU 0 CPU 1 loadmodule notifiercall(MODULESTATECOMING) btfparsemodule btfallocid // Published to userspace listadd(&btfmod->list, btfmodules) mod->init(...) ... ^ bpfcheck | checkpseudobtfid | btftrygetmodule | returns true | ... ... | module init in progress return progfd | ... ... V if (ret < 0) freemodule(mod) ... close(progfd) ... bpfprogfreedeferred moduleput(usedbtf.mod) // use-after-free
We fix this issue by setting a flag BTFMODULEFLIVE, from the notifier callback when MODULESTATELIVE state is reached for the module, so that we return NULL from btftrygetmodule for modules that are not fully formed. Since trymoduleget already checks that module is not in MODULESTATEGOING state, and that is the only transition a live module can make before being removed from btfmodules list, this is enough to close the race and prevent the bug.
A later selftest patch crafts the race condition artifically to verify that it has been fixed, and that verifier fails to load program (with ENXIO).
Lastly, a couple of comments:
1. Even if this race didn't exist, it seems more appropriate to only access resources (ksyms and kfuncs) of a fully formed module which has been initialized completely.
2. This patch was born out of need for synchronization against module initcall for the next patch, so it is needed for correctness even without the aforementioned race condition. The BTF resources initialized by module initcall are set up once and then only looked up, so just waiting until the initcall has finished ensures correct behavior.
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:
phy: stm32: fix a refcount leak in stm32usbphycpllenable()
This error path needs to decrement "usbphyc->npllcons.counter" before returning.