In the Linux kernel, the following vulnerability has been resolved:
writeback: fix race between cgroupwritebackumount() and inodeswitchwbs()
When a container exits, the following BUGON() is occasionally triggered:
================================================================== VFS: Busy inodes after unmount of sdb (ext4) ------------[ cut here ]------------ kernel BUG at fs/super.c:695! CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : genericshutdownsuper+0xf0/0x100 lr : genericshutdownsuper+0xf0/0x100 Call trace: genericshutdownsuper+0xf0/0x100 killblocksuper+0x20/0x48 ext4killsb+0x28/0x60 deactivatelockedsuper+0x54/0x130 deactivatesuper+0x84/0xa0 cleanupmnt+0xa4/0x140 cleanupmnt+0x18/0x28 taskworkrun+0x78/0xe0 donotifyresume+0x204/0x240 ==================================================================
The root cause is a race between cgroupwritebackumount() and inodeswitchwbs()/cleanupofflinecgwb(). There is a window between inodepreparewbsswitch() returning true and the subsequent wbqueueisw() call. Following is the process that triggers the issue:
CPU A (umount) | CPU B (writeback) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inodeswitchwbs/cleanupofflinecgwb atomicinc(&iswnrinflight) inodepreparewbsswitch -> passes SBACTIVE check iget(inode) genericshutdownsuper sb->sflags &= ~SBACTIVE cgroupwritebackumount(sb) smpmb() atomicread(&iswnrinflight) rcubarrier() -> no pending RCU callbacks flushworkqueue(iswwq) -> nothing queued, returns evictinodes(sb) -> Inode skipped as isw still holds a ref. sop->putsuper(sb) / destroys percpu counters / -> VFS: Busy inodes after unmount! wbqueueisw() queuework(iswwq, ...) / later in work function / inodeswitchwbsworkfn processinodeswitchwbs iput() -> evict percpucounterdec() // UAF!
Fix this by extending the RCU read-side critical section in inodeswitchwbs() and cleanupofflinecgwb() to cover from inodepreparewbsswitch() through wbqueueisw(). Since there is no sleep in this window, rcureadlock() can be used. Then add a synchronizercu() in cgroupwritebackumount() before the existing rcubarrier(), so that all in-flight switchers that have passed the SBACTIVE check have completed queuework() before flushworkqueue() is called.
The existing rcubarrier() is intentionally retained so this fix can be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that still queue switches via queuercuwork(). It is a no-op on current mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on wb->listlock when switching inodes")) and is removed in a follow-up patch.
bpf: Free reuseport cBPF prog after RCU grace period.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: ensure names are nul-terminated
Reject names that lack a \0 character before feeding them to functions that expect c-strings.
Fixes tag is the most recent commit that needs this change.
dm-verity: disable recursive forward error correction
In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: Use kernel helpers for hex dumps
Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible.
Therefore, create a new ibmvnic function that loops over a buffer and calls hexdumptobuffer instead.
This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvniclogin+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvniclogin+0x2f0/0xffc [ibmvnic] ibmvnicopen+0x148/0x308 [ibmvnic] devopen+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e
A random memory access flaw was found in the Linux kernel's GPU i915 kernel driver functionality in the way a user may run malicious code on the GPU. This flaw allows a local user to crash the system or escalate their privileges on the system.
A flaw was found in the "Routing decision" classifier in the Linux kernel's Traffic Control networking subsystem in the way it handled changing of classification filters, leading to a use-after-free condition. This flaw allows unprivileged local users to escalate their privileges on the system. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.
A flaw was discovered in processing setsockopt IPTSOSETREPLACE (or IP6TSOSETREPLACE) for 32 bit processes on 64 bit systems. This flaw will allow local user to gain privileges or cause a DoS through user name space. This action is usually restricted to root-privileged users but can also be leveraged if the kernel is compiled with CONFIGUSERNS and CONFIGNETNS and the user is granted elevated privileges.
A flaw was found on the Linux kernel. On the PowerPC platform, the KVM guest allows the OS users to cause host OS memory corruption via rtasargs.nargs. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
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.
A race condition was discovered in ext4writeinlinedataend in fs/ext4/inline.c in the ext4 subsystem in the Linux kernel through 5.13.13.
ibmvnic: Don't reference skb after sending to VIOS
ila: serialize calls to nfregisternethooks()
An information leak flaw was found in the Linux kernel’s IPv6 implementation in the ipv6selectident in net/ipv6/outputcore.c function. The use of a small hash table in IP ID generation allows a remote attacker to reveal sensitive information.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix slab-out-of-bounds in mlx5querynicvportmaclist
mlx5querynicvportmaclist() sizes its firmware command buffer using the PF's logmaxcurrentuc/mclist capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer:
BUG: KASAN: slab-out-of-bounds in mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385
CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5eswwq eswvportchangehandler [mlx5core] Call Trace: <TASK> dumpstacklvl+0x69/0xa0 printreport+0x176/0x4e4 kasanreport+0xc8/0x100 mlx5querynicvportmaclist+0x453/0x4c0 [mlx5core] eswupdatevportaddrlist+0x2e3/0xda0 [mlx5core] eswvportchangehandlelocked+0xa1f/0x1060 [mlx5core] eswvportchangehandler+0x6a/0x90 [mlx5core] processonework+0x87f/0x15e0 workerthread+0x62b/0x1020 kthread+0x375/0x490 retfromfork+0x4dc/0x810 retfromforkasm+0x11/0x20 </TASK>
Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction
Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure.
Now properly rollback the object to its original state upon such failure.
In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcountt: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcountwarnsaturate+0xf4/0x148 Modules linked in: rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) rfkill mlx5core(OE) mlxdevm(OE) ibuverbs(OE) ibcore(OE) psample mlxfw(OE) mlxcompat(OE) macsec tls pcihypervintf sunrpc vfat fat virtionet netfailover failover fuse loop nfnetlink vsockloopback vmwvsockvirtiotransportcommon vmwvsockvmcitransport vmwvmci vsock xfs crct10difce ghashce sha2ce sha256arm64 sha1ce virtioconsole virtiogpu virtioblk virtiodmabuf virtiommio dmmirror dmregionhash dmlog dmmod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcountwarnsaturate+0xf4/0x148 lr : refcountwarnsaturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcountwarnsaturate+0xf4/0x148 mlx5coreputrsc+0x88/0xa0 [mlx5ib] mlx5coredestroyrqtracked+0x64/0x98 [mlx5ib] mlx5ibdestroywq+0x34/0x80 [mlx5ib] ibdestroywquser+0x30/0xc0 [ibcore] uverbsfreewq+0x28/0x58 [ibuverbs] destroyhwidruobject+0x34/0x78 [ibuverbs] uverbsdestroyuobject+0x48/0x240 [ibuverbs] uverbscleanupufile+0xd4/0x1a8 [ibuverbs] uverbsdestroyufilehw+0x48/0x120 [ibuverbs] ibuverbsclose+0x2c/0x100 [ibuverbs] fput+0xd8/0x2f0 fputsync+0x50/0x70 arm64sysclose+0x40/0x90 invokesyscall.constprop.0+0x74/0xd0 doel0svc+0x48/0xe8 el0svc+0x44/0x1d0 el0t64synchandler+0x120/0x130 el0t64sync+0x1a4/0x1a8
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisisas: Grab sasdev lock when traversing the members of sasdev.list
When freeing slots in function slotcompletev3hw(), it is possible that sasdev.list is being traversed elsewhere, and it may trigger a NULL pointer exception, such as follows:
==>cq thread ==>scsieh6
==>scsierrorhandler() ==>sasehhandlesaserrors() ==>sasscsifindtask() ==>llddaborttask() ==>slotcompletev3hw() ==>hisisasaborttask() ==>hisisasslottaskfree() ==>deregdevicev3hw() ==>listdelinit() ==>listforeachentrysafe()
[ 7165.434918] sas: Enter sasscsirecoverhost busy: 32 failed: 32 [ 7165.434926] sas: trying to find task 0x00000000769b5ba5 [ 7165.434927] sas: sasscsifindtask: aborting task 0x00000000769b5ba5 [ 7165.434940] hisisasv3hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted [ 7165.434964] hisisasv3hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored [ 7165.434965] hisisasv3hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored [ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 7165.434972] hisisasv3hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored [ 7165.434975] hisisasv3hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored [ 7165.434976] Mem abort info: [ 7165.434982] ESR = 0x96000004 [ 7165.434991] Exception class = DABT (current EL), IL = 32 bits [ 7165.434992] SET = 0, FnV = 0 [ 7165.434993] EA = 0, S1PTW = 0 [ 7165.434994] Data abort info: [ 7165.434994] ISV = 0, ISS = 0x00000004 [ 7165.434995] CM = 0, WnR = 0 [ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2 [ 7165.434998] [0000000000000000] pgd=0000000000000000 [ 7165.435003] Internal error: Oops: 96000004 [#1] SMP [ 7165.439863] Process scsieh6 (pid: 4109, stack limit = 0x00000000c43818d5) [ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO) [ 7165.473637] pc : deregdevicev3hw+0x68/0xa8 [hisisasv3hw] [ 7165.479443] lr : deregdevicev3hw+0x2c/0xa8 [hisisasv3hw] [ 7165.485247] sp : ffff00001d623bc0 [ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508 [ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8 [ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8 [ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00 [ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8 [ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff [ 7165.520276] x17: 0000000000000000 x16: 0000000000000000 [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8 [ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067 [ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0 [ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00 [ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00 [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e [ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000 [ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e [ 7165.567872] Call trace: [ 7165.570309] deregdevicev3hw+0x68/0xa8 [hisisasv3hw] [ 7165.575775] hisisasaborttask+0x248/0x358 [hisisasmain] [ 7165.581415] sasehhandlesaserrors+0x258/0x8e0 [libsas] [ 7165.586876] sasscsirecoverhost+0x134/0x458 [libsas] [ 7165.592082] scsierrorhandler+0xb4/0x488 [ 7165.596163] kthread+0x134/0x138 [ 7165.599380] retfromfork+0x10/0x18 [ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021) [ 7165.609004] kernel fault(0x1) notification starting on CPU 75 [ 7165.700728] ---[ end trace fc042cbbea224efc ]--- [ 7165.705326] Kernel panic - not syncing: Fatal exception
To fix the issue, grab sasdev lock when traversing the members of sasdev.list in deregdevicev3hw() and hisisasreleasetasks() to avoid concurrency of adding and deleting member. When ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
drm/etnaviv: check for reaped mapping in etnaviviommuunmapgem
When the mapping is already reaped the unmap must be a no-op, as we would otherwise try to remove the mapping twice, corrupting the involved data structures.
In the Linux kernel, the following vulnerability has been resolved:
drbd: Fix five use after free bugs in getinitialstate
In getinitialstate, it calls notifyinitialstatedone(skb,..) if cb->args[5]==1. If genlmsgput() failed in notifyinitialstatedone(), the skb will be freed by nlmsgfree(skb). Then getinitialstate will goto out and the freed skb will be used by return value skb->len, which is a uaf bug.
What's worse, the same problem goes even further: skb can also be freed in the notifystatechange -> notifystate calls below. Thus 4 additional uaf bugs happened.
My patch lets the problem callee functions: notifyinitialstatedone and notifystatechange return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid.
v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/
In the Linux kernel, the following vulnerability has been resolved:
can: dev: canrestart: fix use after free bug
After calling netifrxni(skb), dereferencing skb is unsafe. Especially, the canframe cf which aliases skb memory is accessed after the netifrxni() in: stats->rxbytes += cf->len;
Reordering the lines solves the issue.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: refactor malicious adv data check
Check for out-of-bound read was being performed at the end of while numreports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced.
In the Linux kernel, the following vulnerability has been resolved:
dm btree remove: fix use after free in rebalancechildren()
Move dmtmunlock() after dmtmdec().
In the Linux kernel, the following vulnerability has been resolved:
can: pchcan: pchcanrxnormal: fix use after free
After calling netifreceiveskb(skb), dereferencing skb is unsafe. Especially, the canframe cf which aliases skb memory is dereferenced just after the call netifreceiveskb(skb).
Reordering the lines solves the issue.
In the Linux kernel, the following vulnerability has been resolved:
iio: mma8452: Fix trigger reference couting
The mma8452 driver directly assigns a trigger to the struct iiodev. The IIO core when done using this trigger will call iiotriggerput() to drop the reference count by 1.
Without the matching iiotriggerget() in the driver the reference count can reach 0 too early, the trigger gets freed while still in use and a use-after-free occurs.
Fix this by getting a reference to the trigger before assigning it to the IIO device.
In the Linux kernel, the following vulnerability has been resolved:
IB/qib: Protect from buffer overflow in struct qibusersdmapkt fields
Overflowing either addrlimit or bytestogo can allow userspace to trigger a buffer overflow of kernel memory. Check for overflows in all the places doing math on user controlled buffers.
In the Linux kernel, the following vulnerability has been resolved:
regmap: Fix possible double-free in regcacherbtreeexit()
In regcacherbtreeinserttoblock(), when 'present' realloc failed, the 'blk' which is supposed to assign to 'rbnode->block' will be freed, so 'rbnode->block' points a freed memory, in the error handling path of regcacherbtreeinit(), 'rbnode->block' will be freed again in regcacherbtreeexit(), KASAN will report double-free as follows:
BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 Call Trace: slabfreefreelisthook+0x10d/0x240 kfree+0xce/0x390 regcacherbtreeexit+0x15d/0x1a0 regcacherbtreeinit+0x224/0x2c0 regcacheinit+0x88d/0x1310 regmapinit+0x3151/0x4a80 devmregmapinit+0x7d/0x100 maderaspiprobe+0x10f/0x333 [maderaspi] spiprobe+0x183/0x210 reallyprobe+0x285/0xc30
To fix this, moving up the assignment of rbnode->block to immediately after the reallocation has succeeded so that the data structure stays valid even if the second reallocation fails.
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: mount fails with buffer overflow in strlen
Starting with kernel 5.11 built with CONFIGFORTIFYSOURCE mouting an ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the trace below. Problem seems to be that strings for cluster stack and cluster name are not guaranteed to be null terminated in the disk representation, while strlcpy assumes that the source string is always null terminated. This causes a read outside of the source string triggering the buffer overflow detection.
detected buffer overflow in strlen ------------[ cut here ]------------ kernel BUG at lib/string.c:1149! invalid opcode: 0000 [#1] SMP PTI CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1 Debian 5.14.6-2 RIP: 0010:fortifypanic+0xf/0x11 ... Call Trace: ocfs2initializesuper.isra.0.cold+0xc/0x18 [ocfs2] ocfs2fillsuper+0x359/0x19b0 [ocfs2] mountbdev+0x185/0x1b0 legacygettree+0x27/0x40 vfsgettree+0x25/0xb0 pathmount+0x454/0xa20 x64sysmount+0x103/0x140 dosyscall64+0x3b/0xc0 entrySYSCALL64afterhwframe+0x44/0xae
In the Linux kernel, the following vulnerability has been resolved:
ipack: ipoctal: fix stack information leak
The tty driver name is used also after registering the driver and must specifically not be allocated on the stack to avoid leaking information to user space (or triggering an oops).
Drivers should not try to encode topology information in the tty device name but this one snuck in through staging without anyone noticing and another driver has since copied this malpractice.
Fixing the ABI is a separate issue, but this at least plugs the security hole.
In the Linux kernel, the following vulnerability has been resolved:
tty: Fix out-of-bound vmalloc access in imageblit
The Linux kernel CVE team has assigned CVE-2021-47383 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052144-CVE-2021-47383-a8f4@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
wl1251: Fix possible buffer overflow in wl1251cmdscan
Function wl1251cmdscan calls memcpy without checking the length. Harden by checking the length is within the maximum allowed size.