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

net:emac/emac-mac: Fix a use after free in emacmactxbufsend

In emacmactxbufsend, it calls emactxfilltpd(..,skb,..). If some error happens in emactxfilltpd(), the skb will be freed via devkfreeskb(skb) in error branch of emactxfilltpd(). But the freed skb is still used via skb->len by netdevsentqueue(,skb->len).

As i observed that emactxfilltpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later.

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

sctp: do asoc update earlier in sctpsfdodupcooka

There's a panic that occurs in a few of envs, the call trace is as below:

[] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctpulpeventnotifypeeraddrchange+0x4b/0x1fa [sctp] [] sctpassoccontroltransport+0x1b9/0x210 [sctp] [] sctpdo82transportstrike.isra.16+0x15c/0x220 [sctp] [] sctpcmdinterpreter.isra.21+0x1231/0x1a10 [sctp] [] sctpdosm+0xc3/0x2a0 [sctp] [] sctpgeneratetimeoutevent+0x81/0xf0 [sctp]

This is caused by a transport use-after-free issue. When processing a duplicate COOKIE-ECHO chunk in sctpsfdodupcooka(), both COOKIE-ACK and SHUTDOWN chunks are allocated with the transort from the new asoc. However, later in the sideeffect machine, the old asoc is used to send them out and old asoc's shutdownlastsentto is set to the transport that SHUTDOWN chunk attached to in sctpcmdsetupt2(), which actually belongs to the new asoc. After the newasoc is freed and the old asoc T2 timeout, the old asoc's shutdownlastsentto that is already freed would be accessed in sctpsft2timerexpire().

Thanks Alexander and Jere for helping dig into this issue.

To fix it, this patch is to do the asoc update first, then allocate the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This would make more sense, as a chunk from an asoc shouldn't be sent out with another asoc. We had fixed quite a few issues caused by this.

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

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

mptcp: fix slab-use-after-free in inetlookupestablished

The ehash table lookups are lockless and rely on SLABTYPESAFEBYRCU to guarantee socket memory stability during RCU read-side critical sections. Both tcpprot and tcpv6prot have their slab caches created with this flag via protoregister().

However, MPTCP's mptcpsubflowinit() copies tcpv6prot into tcpv6protoverride during inetinit() (fsinitcall, level 5), before inet6init() (moduleinit/deviceinitcall, level 6) has called protoregister(&tcpv6prot). At that point, tcpv6prot.slab is still NULL, so tcpv6protoverride.slab remains NULL permanently.

This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLABTYPESAFEBYRCU, so when these sockets are freed without SOCKRCUFREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcureadlock can then access freed memory, triggering a slab-use-after-free in inetlookupestablished.

Fix this by splitting the IPv6-specific initialization out of mptcpsubflowinit() into a new mptcpsubflowv6init(), called from mptcpprotov6init() before protocol registration. This ensures tcpv6protoverride.slab correctly inherits the SLABTYPESAFEBYRCU slab cache.

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

smb: client: validate dacloffset before building DACL pointers

parsesecdesc(), buildsecdesc(), and the chown path in idmodetocifsacl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor.

On 32-bit builds a malicious server can return dacloffset near U32MAX, wrap the derived DACL pointer below endofacl, and then slip past the later pointer-based bounds checks. buildsecdesc() and idmodetocifsacl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths.

Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.

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

iommu/vt-d: Remove WO permissions on second-level paging entries

When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration.

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

ath10k: Fix a use after free in ath10khtcsendbundle

In ath10khtcsendbundle, the bundleskb could be freed by devkfreeskbany(bundleskb). But the bundleskb is used later by bundleskb->len.

As skblen = bundleskb->len, my patch replaces bundleskb->len to skblen after the bundleskb was freed.

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:

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.

Last updated 4 July 2026

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

net: qrtr: Avoid potential use after free in MHI send

It is possible that the MHI ulcallback will be invoked immediately following the queueing of the skb for transmission, leading to the callback decrementing the refcount of the associated sk and freeing the skb.

As such the dereference of skb and the increment of the sk refcount must happen before the skb is queued, to avoid the skb to be used after free and potentially the sk to drop its last refcount..

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

Drivers: hv: vmbus: Use after free in vmbusopen()

The "openinfo" variable is added to the &vmbusconnection.chnmsglist, but the error handling frees "openinfo" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it.

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:

openvswitch: fix stack OOB read while fragmenting IPv4 packets

running openvswitch on kernels built with KASAN, it's possible to see the following splat while testing fragmentation of IPv4 packets:

BUG: KASAN: stack-out-of-bounds in ipdofragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367

CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dumpstack+0x92/0xc1 printaddressdescription.constprop.7+0x1a/0x150 kasanreport.cold.13+0x7f/0x111 ipdofragment+0x1b03/0x1f60 ovsfragment+0x5bf/0x840 [openvswitch] doexecuteactions+0x1bd5/0x2400 [openvswitch] ovsexecuteactions+0xc8/0x3d0 [openvswitch] ovspacketcmdexecute+0xa39/0x1150 [openvswitch] genlfamilyrcvmsgdoit.isra.15+0x227/0x2d0 genlrcvmsg+0x287/0x490 netlinkrcvskb+0x120/0x380 genlrcv+0x24/0x40 netlinkunicast+0x439/0x630 netlinksendmsg+0x719/0xbf0 socksendmsg+0xe2/0x110 syssendmsg+0x5ba/0x890 syssendmsg+0xe9/0x160 syssendmsg+0xd3/0x170 dosyscall64+0x33/0x40 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0

The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovsfragment+0x0/0x840 [openvswitch]

this frame has 2 objects: [32, 144) 'ovsdst' [192, 424) 'ovsrt'

Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00

for IPv4 packets, ovsfragment() uses a temporary struct dstentry. Then, in the following call graph:

ipdofragment() ipskbdstmtu() ipdstmtumaybeforward() ipmtulocked()

the pointer to struct dstentry is used as pointer to struct rtable: this turns the access to struct members like rtmtulocked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovsfragment(), similarly to what is done for IPv6 few lines below.

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

net: marvell: prestera: fix port event handling on init

For some reason there might be a crash during ports creation if port events are handling at the same time because fw may send initial port event with down state.

The crash points to canceldelayedwork() which is called when port went is down. Currently I did not find out the real cause of the issue, so fixed it by cancel port stats work only if previous port's state was up & runnig.

The following is the crash which can be triggered:

[ 28.311104] Unable to handle kernel paging request at virtual address 000071775f776600 [ 28.319097] Mem abort info: [ 28.321914] ESR = 0x96000004 [ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits [ 28.330350] SET = 0, FnV = 0 [ 28.333430] EA = 0, S1PTW = 0 [ 28.336597] Data abort info: [ 28.339499] ISV = 0, ISS = 0x00000004 [ 28.343362] CM = 0, WnR = 0 [ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000 [ 28.352842] [000071775f776600] pgd=0000000000000000, p4d=0000000000000000 [ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 28.365310] Modules linked in: presterapci(+) prestera uiopdrvgenirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted 5.11.0-rc4 #1 [ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 28.384283] Workqueue: presterafwwq presterafwevtworkfn [presterapci] [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 28.397468] pc : getworkpool+0x48/0x60 [ 28.401442] lr : trytograbpending+0x6c/0x1b0 [ 28.406018] sp : ffff80001391bc60 [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000 [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88 [ 28.420089] x25: 0000000000000000 x24: ffff000106119760 [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000 [ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0 [ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0 [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88 [ 28.446898] x15: 0000000000000001 x14: 00000000000002ba [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4 [ 28.457622] x11: 0000000000000030 x10: 000000000000000c [ 28.462985] x9 : 000000000000000c x8 : 0000000000000030 [ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758 [ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60 [ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060 [ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8 [ 28.489791] Call trace: [ 28.492259] getworkpool+0x48/0x60 [ 28.495874] canceldelayedwork+0x38/0xb0 [ 28.500011] presteraporthandleevent+0x90/0xa0 [prestera] [ 28.505743] presteraevtrecv+0x98/0xe0 [prestera] [ 28.510683] presterafwevtworkfn+0x180/0x228 [presterapci] [ 28.516660] processonework+0x1e8/0x360 [ 28.520710] workerthread+0x44/0x480 [ 28.524412] kthread+0x154/0x160 [ 28.527670] retfromfork+0x10/0x38 [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020) [ 28.537429] ---[ end trace 5eced933df3a080b ]---

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

Bluetooth: qca: fix info leak when fetching fw build id

Add the missing sanity checks and move the 255-byte build-id buffer off the stack to avoid leaking stack data through debugfs in case the build-info reply is malformed.

An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability.

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

wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes

The Linux kernel CVE team has assigned CVE-2024-35789 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051707-CVE-2024-35789-52e5@gregkh/T

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

bpf: Fix accesses to uninit stack slots

Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocatedstack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in checkstackslotwithinbounds() - in checkstackrangeinitialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - globalfunc16 - because it can't run unprivileged for other reasons.

This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it.

Each function tracks the size of the stack it needs in bpfsubproginfo.stackdepth, which is maintained by updatestackdepth(). For regular memory accesses, checkmemaccess() was calling updatestatedepth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead.

This tracking is now fixed by centralizing the tracking of stack size in growstackstate(), and by lifting the calls to growstackstate() to checkstackaccesswithinbounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. checkstackrangeinitialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue.

A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifiervaroff:stackwriteprivvsunpriv.

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

md/raid1: properly indicate failure when ending a failed write request

This patch addresses a data corruption bug in raid1 arrays using bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared.

Since we are in the failure leg of raid1endwriterequest, the request either needs to be retried (R1BIOWriteError) or failed (R1BIODegraded).

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

scsi: qla2xxx: Fix crash in qla2xxxmqueuecommand()

RIP: 0010:kmemcachefree+0xfa/0x1b0 Call Trace: qla2xxxmqueuecommand+0x2b5/0x2c0 [qla2xxx] scsiqueuerq+0x5e2/0xa40 blkmqtryissuedirectly+0x128/0x1d0 blkmqrequestissuedirectly+0x4e/0xb0

Fix incorrect call to free srb in qla2xxxmqueuecommand(), as srb is now allocated by upper layers. This fixes smatch warning of srb unintended free.

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

btrfs: fix race between transaction aborts and fsyncs leading to use-after-free

There is a race between a task aborting a transaction during a commit, a task doing an fsync and the transaction kthread, which leads to an use-after-free of the log root tree. When this happens, it results in a stack trace like the following:

BTRFS info (device dm-0): forced readonly BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS: error (device dm-0) in cleanuptransaction:1958: errno=-5 IO failure BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5) BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10 BTRFS error (device dm-0): error writing primary super block to device 1 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10 BTRFS: error (device dm-0) in writeallsupers:4110: errno=-5 IO failure (1 errors while writing supers) BTRFS: error (device dm-0) in btrfssynclog:3308: errno=-5 IO failure general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUGPAGEALLOC PTI CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:mutexlock+0x139/0xa40 Code: c0 74 19 (...) RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002 RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040 R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358 FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? btrfshandlefserror+0xde/0x146 [btrfs] ? btrfssynclog+0x7c1/0xf20 [btrfs] ? btrfssynclog+0x7c1/0xf20 [btrfs] btrfssynclog+0x7c1/0xf20 [btrfs] btrfssyncfile+0x40c/0x580 [btrfs] dofsync+0x38/0x70 x64sysfsync+0x10/0x20 dosyscall64+0x33/0x80 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7fa9142a55c3 Code: 8b 15 09 (...) RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIGRAX: 000000000000004a RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3 RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340 R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0 Modules linked in: btrfs dmzero dmsnapshot dmthinpool (...) ---[ end trace ee2f1b19327d791d ]---

The steps that lead to this crash are the following:

1) We are at transaction N;

2) We have two tasks with a transaction handle attached to transaction N. Task A and Task B. Task B is doing an fsync;

3) Task B is at btrfssynclog(), and has saved fsinfo->logroottree into a local variable named 'logroottree' at the top of btrfssynclog(). Task B is about to call writeallsupers(), but before that...

4) Task A calls btrfscommittransaction(), and after it sets the transaction state to TRANSSTATECOMMITSTART, an error happens before it w ---truncated---

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

vhost-vdpa: fix vmflags for virtqueue doorbell mapping

The virtqueue doorbell is usually implemented via registeres but we don't provide the necessary vma->flags like VMPFNMAP. This may cause several issues e.g when userspace tries to map the doorbell via vhost IOTLB, kernel may panic due to the page is not backed by page structure. This patch fixes this by setting the necessary vmflags. With this patch, try to map doorbell via IOTLB will fail with bad address.

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

ACPI: custommethod: fix potential use-after-free issue

In cmwrite(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cmwrite() will still try to access it.

Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function.

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

bus: mhi: core: Fix invalid error returning in mhiqueue

mhiqueue returns an error when the doorbell is not accessible in the current state. This can happen when the device is in non M0 state, like M3, and needs to be waken-up prior ringing the DB. This case is managed earlier by triggering an asynchronous M3 exit via controller resume/suspend callbacks, that in turn will cause M0 transition and DB update.

So, since it's not an error but just delaying of doorbell update, there is no reason to return an error.

This also fixes a use after free error for skb case, indeed a caller queuing skb will try to free the skb if the queueing fails, but in that case queueing has been done.

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

media: atomisp: Fix use after free in atomispalloccssstatbufs()

The "s3abuf" is freed along with all the other items on the "asd->s3astats" list. It leads to a double free and a use after free.

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

kyber: fix out of bounds access when preempted

blkmqschedbiomerge() gets the ctx and hctx for the current CPU and passes the hctx to ->biomerge(). kyberbiomerge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blkmqgetctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->indexhw[hctx->type] > hctx->nrctx).

This manifested as this UBSAN array index out of bounds error reported by Jakub:

UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dumpstack+0xa4/0xe5 ubsanepilogue+0x5/0x40 ubsanhandleoutofbounds.cold.13+0x2a/0x34 queuedspinlockslowpath+0x476/0x480 dorawspinlock+0x1c2/0x1d0 kyberbiomerge+0x112/0x180 blkmqsubmitbio+0x1f5/0x1100 submitbionoacct+0x7b0/0x870 submitbio+0xc2/0x3a0 btrfsmapbio+0x4f0/0x9d0 btrfssubmitdatabio+0x24e/0x310 submitonebio+0x7f/0xb0 submitextentpage+0xc4/0x440 extentwritepageio+0x2b8/0x5e0 extentwritepage+0x28d/0x6e0 extentwritecachepages+0x4d7/0x7a0 extentwritepages+0xa2/0x110 dowritepages+0x8f/0x180 writebacksingleinode+0x99/0x7f0 writebacksbinodes+0x34e/0x790 writebackinodeswb+0x9e/0x120 wbwriteback+0x4d2/0x660 wbworkfn+0x64d/0xa10 processonework+0x53a/0xa80 workerthread+0x69/0x5b0 kthread+0x20b/0x240 retfromfork+0x1f/0x30

Only Kyber uses the hctx, so fix it by passing the requestqueue to ->biomerge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch.

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

netfilter: nftables: avoid overflows in nfthashbuckets()

Number of buckets being stored in 32bit variables, we have to ensure that no overflows occur in nfthashbuckets()

syzbot injected a size == 0x40000000 and reported:

UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: dumpstack lib/dumpstack.c:79 [inline] dumpstack+0x141/0x1d7 lib/dumpstack.c:120 ubsanepilogue+0xb/0x5a lib/ubsan.c:148 ubsanhandleshiftoutofbounds.cold+0xb1/0x181 lib/ubsan.c:327 rounduppowoftwo include/linux/log2.h:57 [inline] nfthashbuckets net/netfilter/nftsethash.c:411 [inline] nfthashestimate.cold+0x19/0x1e net/netfilter/nftsethash.c:652 nftselectsetops net/netfilter/nftablesapi.c:3586 [inline] nftablesnewset+0xe62/0x3110 net/netfilter/nftablesapi.c:4322 nfnetlinkrcvbatch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlinkrcvskbbatch net/netfilter/nfnetlink.c:612 [inline] nfnetlinkrcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlinkunicastkernel net/netlink/afnetlink.c:1312 [inline] netlinkunicast+0x533/0x7d0 net/netlink/afnetlink.c:1338 netlinksendmsg+0x856/0xd90 net/netlink/afnetlink.c:1927 socksendmsgnosec net/socket.c:654 [inline] socksendmsg+0xcf/0x120 net/socket.c:674 syssendmsg+0x6e8/0x810 net/socket.c:2350 syssendmsg+0xf3/0x170 net/socket.c:2404 syssendmsg+0xe5/0x1b0 net/socket.c:2433 dosyscall64+0x2d/0x70 arch/x86/entry/common.c:46

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

RDMA/siw: Fix a use after free in siwallocmr

Our code analyzer reported a UAF.

In siwallocmr(), it calls siwmraddmem(mr,..). In the implementation of siwmraddmem(), mem is assigned to mr->mem and then mem is freed via kfree(mem) if xaalloccyclic() failed. Here, mr->mem still point to a freed object. After, the execution continue up to the errout branch of siwallocmr, and the freed mr->mem is used in siwmrdropmem(mr).

My patch moves "mr->mem = mem" behind the if (xaalloccyclic(..)<0) {} section, to avoid the uaf.