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.
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.
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:
wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmffwallocrequest()
This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITSPERTYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmfusbprobecb() or brcmfusbresetresume(), for example.
Found by a modified version of syzkaller.
UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usbhubwq hubevent Call Trace: dumpstacklvl+0x57/0x7d ubsanepilogue+0x5/0x40 ubsanhandleshiftoutofbounds.cold+0x53/0xdb ? lockchaincount+0x20/0x20 brcmffwallocrequest.cold+0x19/0x3ea ? brcmffwgetfirmwares+0x250/0x250 ? brcmfusbioctlrespwait+0x1a7/0x1f0 brcmfusbgetfwname+0x114/0x1a0 ? brcmfusbresetresume+0x120/0x120 ? number+0x6c4/0x9a0 brcmfcprocessclmblob+0x168/0x590 ? putdec+0x90/0x90 ? enableptrkeyworkfn+0x20/0x20 ? brcmfcommonpdremove+0x50/0x50 ? rcureadlockschedheld+0xa1/0xd0 brcmfcpreinitdcmds+0x673/0xc40 ? brcmfcsetjoinprefdefault+0x100/0x100 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockacquire+0x19d/0x4e0 ? findheldlock+0x2d/0x110 ? brcmfusbdeq+0x1cc/0x260 ? markheldlocks+0x9f/0xe0 ? lockdephardirqsonprepare+0x273/0x3e0 ? rawspinunlockirqrestore+0x47/0x50 ? tracehardirqson+0x1c/0x120 ? brcmfusbdeq+0x1a7/0x260 ? brcmfusbrxfillall+0x5a/0xf0 brcmfattach+0x246/0xd40 ? wiphynewnm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmfusbprobe+0x12de/0x1690 ? brcmfusbdevqinit.constprop.0+0x470/0x470 usbprobeinterface+0x25f/0x710 reallyprobe+0x1be/0xa90 driverprobedevice+0x2ab/0x460 ? usbmatchid.part.0+0x88/0xc0 driverprobedevice+0x49/0x120 deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? mutexunlockslowpath+0xe7/0x660 ? fwdevlinklinktosuppliers+0x550/0x550 usbsetconfiguration+0x984/0x1770 ? kernfscreatelink+0x175/0x230 usbgenericdriverprobe+0x69/0x90 usbprobedevice+0x9c/0x220 reallyprobe+0x1be/0xa90 driverprobedevice+0x2ab/0x460 driverprobedevice+0x49/0x120 deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? fwdevlinklinktosuppliers+0x550/0x550 usbnewdevice.cold+0x463/0xf66 ? hubdisconnect+0x400/0x400 ? rawspinunlockirq+0x24/0x30 hubevent+0x10d5/0x3330 ? hubportdebounce+0x280/0x280 ? lockacquire+0x1671/0x5790 ? wqcalcnodecpumask+0x170/0x2a0 ? lockrelease+0x640/0x640 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockdephardirqsonprepare+0x273/0x3e0 processonework+0x873/0x13e0 ? lockrelease+0x640/0x640 ? pwqdecnrinflight+0x320/0x320 ? rwlockbug.part.0+0x90/0x90 workerthread+0x8b/0xd10 ? kthreadparkme+0xd9/0x1d0 ? pr ---truncated---
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:
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:
net: stmmac: make sure that ptprate is not 0 before configuring timestamping
The stmmac platform drivers that do not open-code the clkptprate value after having retrieved the default one from the device-tree can end up with 0 in clkptprate (as clkgetrate can return 0). It will eventually propagate up to PTP initialization when bringing up the interface, leading to a divide by 0:
Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x6c/0x8c dumpstacklvl from Ldiv064+0x8/0x18 Ldiv064 from stmmacinittstampcounter+0x190/0x1a4 stmmacinittstampcounter from stmmachwsetup+0xc1c/0x111c stmmachwsetup from stmmacopen+0x18c/0x434 stmmacopen from stmmacopen+0x3c/0xbc stmmacopen from devopen+0xf4/0x1ac devopen from devchangeflags+0x1cc/0x224 devchangeflags from devchangeflags+0x24/0x60 devchangeflags from ipautoconfig+0x2e8/0x11a0 ipautoconfig from dooneinitcall+0x84/0x33c dooneinitcall from kernelinitfreeable+0x1b8/0x214 kernelinitfreeable from kernelinit+0x24/0x140 kernelinit from retfromfork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8)
Prevent this division by 0 by adding an explicit check and error log about the actual issue. While at it, remove the same check from stmmacptpregister, which then becomes duplicate
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v2m: Prevent use after free of gicv2mgetfwnode()
With ACPI in place, gicv2mgetfwnode() is registered with the pci subsystem as pcimsigetfwnodecb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as init, causing it to be freed, while being registered with the PCI subsystem and could trigger:
Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2mgetfwnode+0x0/0x58 (P) pcisetbusmsidomain+0x74/0x88 pciregisterhostbridge+0x194/0x548
This is easily reproducible on a Juno board with ACPI boot.
Retain the function for later use.
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:
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
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: validate parameter addr in mdiobusgetphy()
The caller may pass any value as addr, what may result in an out-of-bounds access to array mdiomap. One existing case is stmmacinitphy() that may pass -1 as addr. Therefore validate addr before using it.
ibmvnic: Don't reference skb after sending to VIOS
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/
iio: dummy: iiosimplydummybuffer: fix information leak in triggered buffer
ila: serialize calls to nfregisternethooks()
In the Linux kernel, the following vulnerability has been resolved:
net: mvneta: Prevent out of bounds read in mvnetaconfigrss()
The pp->indir[0] value comes from the user. It is passed to:
if (cpuonline(pp->rxqdef))
inside the mvnetapercpuelect() function. It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap.
ila: call nfunregisternethooks() sooner
In the Linux kernel, the following vulnerability has been resolved:
isdn: cpai: check ctr->cnr to avoid array index out of bound
The cmtpaddconnection() would add a cmtp session to a controller and run a kernel thread to process cmtp.
moduleget(THISMODULE); session->task = kthreadrun(cmtpsession, session, "kcmtpdctr%d", session->num);
During this process, the kernel thread would call detachcapictr() to detach a register controller. if the controller was not attached yet, detachcapictr() would trigger an array-index-out-bounds bug.
[ 46.866069][ T6479] UBSAN: array-index-out-of-bounds in drivers/isdn/capi/kcapi.c:483:21 [ 46.867196][ T6479] index -1 is out of range for type 'capictr [32]' [ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpdctr0 Not tainted 5.15.0-rc2+ #8 [ 46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 46.870107][ T6479] Call Trace: [ 46.870473][ T6479] dumpstacklvl+0x57/0x7d [ 46.870974][ T6479] ubsanepilogue+0x5/0x40 [ 46.871458][ T6479] ubsanhandleoutofbounds.cold+0x43/0x48 [ 46.872135][ T6479] detachcapictr+0x64/0xc0 [ 46.872639][ T6479] cmtpsession+0x5c8/0x5d0 [ 46.873131][ T6479] ? initwaitqueuehead+0x60/0x60 [ 46.873712][ T6479] ? cmtpaddmsgpart+0x120/0x120 [ 46.874256][ T6479] kthread+0x147/0x170 [ 46.874709][ T6479] ? setkthreadstruct+0x40/0x40 [ 46.875248][ T6479] retfromfork+0x1f/0x30 [ 46.875773][ T6479]
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix hang in usbkillurb by adding memory barriers
The Linux kernel CVE team has assigned CVE-2022-48760 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024062008-CVE-2022-48760-b80e@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
net: fix information leakage in /proc/net/ptype
In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new packettype added by this packet socket by reading /proc/net/ptype file. This is minor information leakage as packet socket is namespace aware.
Add a net pointer in packettype to keep the net namespace of of corresponding packet socket. In ptypeseqshow, this net pointer must be checked when it is not NULL.
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:
igbvf: fix double free in igbvfprobe
In igbvfprobe, if registernetdev() fails, the program will go to label errhwinit, and then to label errioremap. In freenetdev() which is just below label errioremap, there is listforeachentrysafe and netifnapidel which aims to delete all entries in dev->napilist. The program has added an entry adapter->rxring->napi which is added by netifnapiadd in igbvfallocqueues(). However, adapter->rxring has been freed below label errhwinit. So this a UAF.
In terms of how to patch the problem, we can refer to igbvfremove() and delete the entry before adapter->rxring.
The KASAN logs are as follows:
[ 35.126075] BUG: KASAN: use-after-free in freenetdev+0x1fd/0x450 [ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366 [ 35.128360] [ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14 [ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 35.131749] Call Trace: [ 35.132199] dumpstacklvl+0x59/0x7b [ 35.132865] printaddressdescription+0x7c/0x3b0 [ 35.133707] ? freenetdev+0x1fd/0x450 [ 35.134378] kasanreport+0x160/0x1c0 [ 35.135063] ? freenetdev+0x1fd/0x450 [ 35.135738] kasanreport+0x4b/0x70 [ 35.136367] freenetdev+0x1fd/0x450 [ 35.137006] igbvfprobe+0x121d/0x1a10 [igbvf] [ 35.137808] ? igbvfvlanrxaddvid+0x100/0x100 [igbvf] [ 35.138751] localpciprobe+0x13c/0x1f0 [ 35.139461] pcideviceprobe+0x37e/0x6c0 [ 35.165526] [ 35.165806] Allocated by task 366: [ 35.166414] kasankmalloc+0xc4/0xf0 [ 35.167117] fookmemcachealloctrace+0x3c/0x50 [igbvf] [ 35.168078] igbvfprobe+0x9c5/0x1a10 [igbvf] [ 35.168866] localpciprobe+0x13c/0x1f0 [ 35.169565] pcideviceprobe+0x37e/0x6c0 [ 35.179713] [ 35.179993] Freed by task 366: [ 35.180539] kasansettrack+0x4c/0x80 [ 35.181211] kasansetfreeinfo+0x1f/0x40 [ 35.181942] kasanslabfree+0x103/0x140 [ 35.182703] kfree+0xe3/0x250 [ 35.183239] igbvfprobe+0x1173/0x1a10 [igbvf] [ 35.184040] localpciprobe+0x13c/0x1f0
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8192e: Fix use after free in rtl92epcidisconnect()
The freertllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that.
In the Linux kernel, the following vulnerability has been resolved:
proc/vmcore: fix clearing user buffer by properly using clearuser()
The Linux kernel CVE team has assigned CVE-2021-47566 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052453-CVE-2021-47566-12b8@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix kernel panic during drive powercycle test
While looping over shost's sdev list it is possible that one of the drives is getting removed and its sastarget object is freed but its sdev object remains intact.
Consequently, a kernel panic can occur while the driver is trying to access the sasaddress field of sastarget object without also checking the sastarget object for NULL.
In the Linux kernel, the following vulnerability has been resolved:
satafsl: fix UAF in satafslportstop when rmmod satafsl
When the rmmod satafsl.ko command is executed in the PPC64 GNU/Linux, a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .satafslportstop+0x44/0xe0 [satafsl] Call Trace: .freeirq+0x1c/0x4e0 (unreliable) .atahoststop+0x74/0xd0 [libata] .releasenodes+0x330/0x3f0 .devicereleasedriverinternal+0x178/0x2c0 .driverdetach+0x64/0xd0 .busremovedriver+0x70/0xf0 .driverunregister+0x38/0x80 .platformdriverunregister+0x14/0x30 .fslsatadriverexit+0x18/0xa20 [satafsl] .sesysdeletemodule+0x1ec/0x2d0 .systemcallexception+0xfc/0x1f0 systemcallcommon+0xf8/0x200 ==================================================================
The triggering of the BUG is shown in the following stack:
driverdetach devicereleasedriverinternal devicereleasedriver drv->remove(dev) --> platformdrvremove/platformremove drv->remove(dev) --> satafslremove iounmap(hostpriv->hcrbase); <---- unmap kfree(hostpriv); <---- free devresreleaseall releasenodes dr->node.release(dev, dr->data) --> atahoststop ap->ops->portstop(ap) --> satafslportstop ioread32(hcrbase + HCONTROL) <---- UAF host->ops->hoststop(host)
The iounmap(hostpriv->hcrbase) and kfree(hostpriv) functions should not be executed in drv->remove. These functions should be executed in hoststop after portstop. Therefore, we move these functions to the new function satafslhoststop and bind the new function to hoststop.