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.

In the Linux kernel, the following vulnerability has been resolved:

mm/hugememory: fix folio isn't locked in softleaftofolio()

On arm64 server, we found folio that get from migration entry isn't locked in softleaftofolio(). This issue triggers when mTHP splitting and zapnonpresentptes() races, and the root cause is lack of memory barrier in softleaftofolio(). The race is as follows:

CPU0 CPU1

deferredsplitscan() zapnonpresentptes() lock folio splitfolio() unmapfolio() change ptes to migration entries splitfoliotoorder() softleaftofolio() set flags(including PGlocked) for tail pages folio = pfnfolio(softleaftopfn(entry)) smpwmb() VMWARNONONCE(!foliotestlocked(folio)) prepcompoundpage() for tail pages

In splitfoliotoorder(), smpwmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smpwmb() should be paired with smprmb() in softleaftofolio(), which is missed. As a result, if zapnonpresentptes() accesses migration entry that stores tail pfn, softleaftofolio() may see the updated compoundhead of tail page before page->flags.

This issue will trigger VMWARNONONCE() in pfnswapentryfolio() because of the race between folio split and zapnonpresentptes() leading to a folio incorrectly undergoing modification without a folio lock being held.

This is a BUGON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1.

To fix it, add missing smprmb() if the softleaf entry is migration entry in softleaftofolio() and softleaftopage().

[tujinjiang@huawei.com: update function name and comments]

In the Linux kernel, the following vulnerability has been resolved:

net/sched: teql: fix NULL pointer dereference in iptunnelxmit on TEQL slave xmit

teqlmasterxmit() calls netdevstartxmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand.

When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnelxmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnelxmitstats(dev, pktlen). This function does:

getcpuptr(dev->tstats)

Since teqlmastersetup() does not set dev->pcpustattype to NETDEVPCPUSTATTSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. getcpuptr(NULL) computes NULL + percpuoffset[cpu], resulting in a page fault.

BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnelxmit (./include/net/iptunnels.h:664 net/ipv4/iptunnelcore.c:89) Call Trace: <TASK> iptunnelxmit (net/ipv4/iptunnel.c:847) grexmit (net/ipv4/ipgre.c:478) gretapxmit (net/ipv4/ipgre.c:779) teqlmasterxmit (net/sched/schteql.c:319) devhardstartxmit (net/core/dev.c:3887) schdirectxmit (net/sched/schgeneric.c:347) devqueuexmit (net/core/dev.c:4802) neighdirectoutput (net/core/neighbour.c:1660) ipfinishoutput2 (net/ipv4/ipoutput.c:237) ipfinishoutput.part.0 (net/ipv4/ipoutput.c:315) ipmcoutput (net/ipv4/ipoutput.c:369) ipsendskb (net/ipv4/ipoutput.c:1508) udpsendskb (net/ipv4/udp.c:1195) udpsendmsg (net/ipv4/udp.c:1485) inetsendmsg (net/ipv4/afinet.c:859) syssendto (net/socket.c:2206)

Fix this by setting skb->dev = slave before calling netdevstartxmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.

In the Linux kernel, the following vulnerability has been resolved:

dm-verity: disable recursive forward error correction

There are two problems with the recursive correction:

1. It may cause denial-of-service. In fecreadbufs, there is a loop that has 253 iterations. For each iteration, we may call verityhashforblock recursively. There is a limit of 4 nested recursions - that means that there may be at most 253^4 (4 billion) iterations. Red Hat QE team actually created an image that pushes dm-verity to this limit - and this image just makes the udev-worker process get stuck in the 'D' state.

2. It doesn't work. In fecreadbufs we store data into the variable "fio->bufs", but fio bufs is shared between recursive invocations, if "verityhashforblock" invoked correction recursively, it would overwrite partially filled fio->bufs.

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 &lt;...&gt; 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 &lt;...&gt; Allocated by task 17681: &lt;...&gt; ibmvniclogin+0x2f0/0xffc [ibmvnic] ibmvnicopen+0x148/0x308 [ibmvnic] devopen+0x1ac/0x304 &lt;...&gt; The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) &lt;...&gt; ================================================================= 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

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix potential deadlock with newly created symlinks

Syzbot reported that pagesymlink(), called by nilfssymlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->nssegctorsem, swriters percpurwsem (intwrite) and the fsreclaim pseudo lock.

This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFPKERNEL via inodenohighmem().

This is not a problem for symlinks read from the backing device, because the GFPFS flag is dropped after inodenohighmem() is called. However, when a new symlink is created with nilfssymlink(), the gfp flags remain overwritten to GFPKERNEL. Then, memory allocation called from pagesymlink() etc. triggers memory reclamation including the FS layer, which may call nilfsevictinode() or nilfsdirtyinode(). And these can cause a deadlock if they are called while nilfs->nssegctorsem is held:

Fix this issue by dropping the GFPFS flag from the page cache GFP flags of newly created symlinks in the same way that nilfsnewinode() and nilfsreadinode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.

ila: serialize calls to nfregisternethooks()

fsl/fman: Fix refcount handling of fman-related devices

In the Linux kernel, the following vulnerability has been resolved:

scsi: hisisas: Free irq vectors in order for v3 HW

If the driver probe fails to request the channel IRQ or fatal IRQ, the driver will free the IRQ vectors before freeing the IRQs in freeirq(), and this will cause a kernel BUG like this:

------------[ cut here ]------------ kernel BUG at drivers/pci/msi.c:369! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: freemsiirqs+0x118/0x13c pcidisablemsi+0xfc/0x120 pcifreeirqvectors+0x24/0x3c hisisasv3probe+0x360/0x9d0 [hisisasv3hw] localpciprobe+0x44/0xb0 workforcpufn+0x20/0x34 processonework+0x1d0/0x340 workerthread+0x2e0/0x460 kthread+0x180/0x190 retfromfork+0x10/0x20 ---[ end trace b88990335b610c11 ]---

So we use devmaddaction() to control the order in which we free the vectors.

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:

drbd: add missing krefget in handlewriteconflicts

With two-primaries enabled, DRBD tries to detect "concurrent" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed.

In handling "superseeded" writes, we forgot a krefget, resulting in a premature drbddestroydevice and use after free, and further to kernel crashes with symptoms.

Relevance: No one should use DRBD as a random data generator, and apparently all users of "two-primaries" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node.

Which means that other than for "test cases", this code path is never taken in real life.

FYI, in DRBD 9, things are handled differently nowadays. We still detect "write conflicts", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.

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:

net: systemport: Add global locking for descriptor lifecycle

The descriptor list is a shared resource across all of the transmit queues, and the locking mechanism used today only protects concurrency across a given transmit queue between the transmit and reclaiming. This creates an opportunity for the SYSTEMPORT hardware to work on corrupted descriptors if we have multiple producers at once which is the case when using multiple transmit queues.

This was particularly noticeable when using multiple flows/transmit queues and it showed up in interesting ways in that UDP packets would get a correct UDP header checksum being calculated over an incorrect packet length. Similarly TCP packets would get an equally correct checksum computed by the hardware over an incorrect packet length.

The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges when the driver produces a new descriptor anytime it writes to the WRITEPORT{HI,LO} registers, there is however some delay in the hardware to re-organize its descriptors and it is possible that concurrent TX queues eventually break this internal allocation scheme to the point where the length/status part of the descriptor gets used for an incorrect data buffer.

The fix is to impose a global serialization for all TX queues in the short section where we are writing to the WRITEPORT{HI,LO} registers which solves the corruption even with multiple concurrent TX queues being used.

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.