gfs2: Fix NULL pointer dereference in gfs2logflush

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

netfilter: bridge: replace physindev with physinif in nfbridgeinfo

An skb can be added to a neigh->arpqueue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arpqueue of the bridge.

As skb->dev can be reset back to nfbridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neighflushdev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack:

arpprocess neighupdate skb = skbdequeue(&neigh->arpqueue) neighresolveoutput(..., skb) ... brnfdevxmit brnfpreroutingfinishbridgeslow skb->dev = nfbridge->physindev brhandleframefinish

Let's use plain ifindex instead of netdevice link. To peek into the original netdevice we will use devgetbyindexrcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.

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

netfilter: nftables: Fix potential data-race in nftflowtabletypeget()

nftunregisterflowtabletype() within nfflowinetmoduleexit() can concurrent with nftflowtabletypeget() within nftablesnewflowtable(). And thhere is not any protection when iterate over nftablesflowtables list in nftflowtabletypeget(). Therefore, there is pertential data-race of nftablesflowtables list entry.

Use listforeachentryrcu() to iterate over nftablesflowtables list in nftflowtabletypeget(), and use rcureadlock() in the caller nftflowtabletypeget() to protect the entire type query process.

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

netfilter: nftsetpipapo: walk over current view on netlink dump

The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set.

Based on patch from Florian Westphal.

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

memcg: protect concurrent access to memcgroupidr

Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the memcgroupidr, the idralloc() and idrreplace() happen within css callback and thus are protected through cgroupmutex from concurrent modifications. However idrremove() for memcgroupidr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that.

We have been seeing listlru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of listlru code including listlruadd(), listlrudel() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the superblock's listlru didn't have listlruone for the memcg of that object. The initial suspicions were either the object is not allocated through kmemcachealloclru() or somehow memcglistlrualloc() failed to allocate listlruone() for a memcg but returned success. No evidence were found for these cases.

Looking more deeply, we started seeing situations where valid memcg's id is not present in memcgroupidr and in some cases multiple valid memcgs have same id and memcgroupidr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idrremove() calls or race between idralloc()/idrreplace() and idrremove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup listlrus on the system for all of them. Later access from other memcgs to the listlru cause crashes due to missing listlruone.

i40e: fix race condition by adding filter's intermediate sync state

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

mptcp: cope racing subflow creation in mptcprcvspaceadjust

Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs.

A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcpcleanuprbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones.

Explicitly check that the subflow is in a suitable state before invoking tcpcleanuprbuf().

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

lib/generic-radix-tree.c: Fix rare race in genradixptralloc()

If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later.

If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path.

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

mlxsw: spectrumaclerp: Fix object nesting warning

ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can contain more ACLs (i.e., tc filters), but the number of masks in each region (i.e., tc chain) is limited.

In order to mitigate the effects of the above limitation, the device allows filters to share a single mask if their masks only differ in up to 8 consecutive bits. For example, dstip/25 can be represented using dstip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the number of masks being used (and therefore does not support mask aggregation), but can contain a limited number of filters.

The driver uses the "objagg" library to perform the mask aggregation by passing it objects that consist of the filter's mask and whether the filter is to be inserted into the A-TCAM or the C-TCAM since filters in different TCAMs cannot share a mask.

The set of created objects is dependent on the insertion order of the filters and is not necessarily optimal. Therefore, the driver will periodically ask the library to compute a more optimal set ("hints") by looking at all the existing objects.

When the library asks the driver whether two objects can be aggregated the driver only compares the provided masks and ignores the A-TCAM / C-TCAM indication. This is the right thing to do since the goal is to move as many filters as possible to the A-TCAM. The driver also forbids two identical masks from being aggregated since this can only happen if one was intentionally put in the C-TCAM to avoid a conflict in the A-TCAM.

The above can result in the following set of hints:

H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta H3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta

After getting the hints from the library the driver will start migrating filters from one region to another while consulting the computed hints and instructing the device to perform a lookup in both regions during the transition.

Assuming a filter with mask X is being migrated into the A-TCAM in the new region, the hints lookup will return H1. Since H2 is the parent of H1, the library will try to find the object associated with it and create it if necessary in which case another hints lookup (recursive) will be performed. This hints lookup for {mask Y, A-TCAM} will either return H2 or H3 since the driver passes the library an object comparison function that ignores the A-TCAM / C-TCAM indication.

This can eventually lead to nested objects which are not supported by the library [1].

Fix by removing the object comparison function from both the driver and the library as the driver was the only user. That way the lookup will only return exact matches.

I do not have a reliable reproducer that can reproduce the issue in a timely manner, but before the fix the issue would reproduce in several minutes and with the fix it does not reproduce in over an hour.

Note that the current usefulness of the hints is limited because they include the C-TCAM indication and represent aggregation that cannot actually happen. This will be addressed in net-next.

[1] WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objaggobjparentassign+0xb5/0xd0 Modules linked in: CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42 Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork RIP: 0010:objaggobjparentassign+0xb5/0xd0 [...] Call Trace: objaggobjget+0x2bb/0x580 objaggobjget+0xe/0x80 mlxswspaclerpmaskget+0xb5/0xf0 mlxswspaclatcamentryadd+0xe8/0x3c0 mlxswspacltcamentrycreate+0x5e/0xa0 mlxswspacltcamvchunkmigrateone+0x16b/0x270 mlxswspacltcamvregionrehashwork+0xbe/0x510 processonework+0x151/0x370

dev/parport: fix the array out-of-bounds risk

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

tipc: Return non-zero value from tipcudpaddr2str() on error

tipcudpaddr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipcmediaaddrprintf(). Fix this by returning 1 on an invalid UDP media address.

drm/i915/gt: Fix potential UAF by revoke of fence registers

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

ibmvnic: Add tx check to prevent skb leak

Below is a summary of how the driver stores a reference to an skb during transmit: txbuff[freemap[consumerindex]]->skb = newskb; freemap[consumerindex] = IBMVNICINVALIDMAP; consumerindex ++; Where variable data looks like this: freemap == [4, IBMVNICINVALIDMAP, IBMVNICINVALIDMAP, 0, 3] consumerindex^ txbuff == [skb=null, skb=, skb=, skb=null, skb=null]

The driver has checks to ensure that freemap[consumerindex] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our freemap and txbuff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT.

Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.

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

bpf: Fix overrunning reservations in ringbuf

The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumerpos is the consumer counter to show which logical position the consumer consumed the data, and producerpos which is the producer counter denoting the amount of data reserved by all producers.

Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write.

One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory.

Each record has a struct bpfringbufhdr { u32 len; u32 pgoff; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpfringbufreserve() return (void )hdr + BPFRINGBUFHDRSZ for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header.

For example, consider the creation of a BPFMAPTYPERINGBUF map with size of 0x4000. Next, the consumerpos is modified to 0x3000 /before/ a call to bpfringbufreserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumerpos was edited ahead of time to pass the newprodpos - conspos > rb->mask check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpfringbufsubmit() / bpfringbufdiscard() use the header's pgoff to then locate the bpfringbuf itself via bpfringbufrestorefromrec(). Once chunk B modified chunk A's header, then bpfringbufcommit() refers to the wrong page and could cause a crash.

Fix it by calculating the oldest pendingpos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/runbenchringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.

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

ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."

Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present.

However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference.

Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions.

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

tipc: force a dst refcount before doing decryption

As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"):

"Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers."

On TIPC decryption path it has the same problem, and skbdstforce() should be called before doing decryption to avoid a possible crash.

Shuang reported this issue when this warning is triggered:

[] WARNING: include/net/dst.h:337 tipcskrcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x8664+debug [] Workqueue: crypto cryptdqueueworker [] RIP: 0010:tipcskrcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipcskmcastrcv+0x548/0xea0 [tipc] [] tipcrcv+0xcf5/0x1060 [tipc] [] tipcaeaddecryptdone+0x215/0x2e0 [tipc] [] cryptdaeadcrypt+0xdb/0x190 [] cryptdqueueworker+0xed/0x190 [] processonework+0x93d/0x17e0

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

drm/i915/dpt: Make DPT object unshrinkable

In some scenarios, the DPT object gets shrunk but the actual framebuffer did not and thus its still there on the DPT's vm->boundlist. Then it tries to rewrite the PTEs via a stale CPU mapping. This causes panic.

[vsyrjala: Add TODO comment] (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)

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

netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type

Lion Ackermann reported that there is a race condition between namespace cleanup in ipset and the garbage collection of the list:set type. The namespace cleanup can destroy the list:set type of sets while the gc of the set type is waiting to run in rcu cleanup. The latter uses data from the destroyed set which thus leads use after free. The patch contains the following parts:

- When destroying all sets, first remove the garbage collectors, then wait if needed and then destroy the sets. - Fix the badly ordered "wait then remove gc" for the destroy a single set case. - Fix the missing rcu locking in the list:set type in the userspace test case. - Use proper RCU list handlings in the list:set type.

The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancelgc).

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

of: module: add buffer overflow check in ofmodalias()

In ofmodalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).

dma-direct: Leak pages on dmasetdecrypted() failure

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

nouveau: lock the client object tree.

It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings.

4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkmobjectsearch+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] [ 4562.099573] ? dieaddr+0x36/0x90 [ 4562.099583] ? excgeneralprotection+0x246/0x4a0 [ 4562.099593] ? asmexcgeneralprotection+0x26/0x30 [ 4562.099600] ? nvkmobjectsearch+0x1d/0x70 [nouveau] [ 4562.099730] nvkmioctl+0xa1/0x250 [nouveau] [ 4562.099861] nvifobjectmaphandle+0xc8/0x180 [nouveau] [ 4562.099986] nouveauttmiomemreserve+0x122/0x270 [nouveau] [ 4562.100156] ? dmaresvtestsignaled+0x26/0xb0 [ 4562.100163] ttmbovmfaultreserved+0x97/0x3c0 [ttm] [ 4562.100182] ? mutexunlockslowpath+0x2a/0x270 [ 4562.100189] nouveauttmfault+0x69/0xb0 [nouveau] [ 4562.100356] dofault+0x32/0x150 [ 4562.100362] dofault+0x7c/0x560 [ 4562.100369] handlemmfault+0x800/0xc10 [ 4562.100382] handlemmfault+0x17c/0x3e0 [ 4562.100388] douseraddrfault+0x208/0x860 [ 4562.100395] excpagefault+0x7f/0x200 [ 4562.100402] asmexcpagefault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] [ 4562.100448] Modules linked in: nfconntracknetbiosns nfconntrackbroadcast nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intelraplmsr intelraplcommon sndsofpciintelcnl x86pkgtempthermal intelpowerclamp sndsofintelhdacommon mac80211 coretemp sndsocacpiintelmatch kvmintel sndsocacpi sndsochdachda sndsofpci sndsofxtensadsp sndsofintelhdamlink ---truncated---

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

KVM: Always flush async #PF workqueue when vCPU is being destroyed

Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM module is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes.

Drop the misguided VM refcount gifting, as calling kvmputkvm() from asyncpfexecute() if kvmputkvm() flushes the async #PF workqueue will result in deadlock. asyncpfexecute() can't return until kvmputkvm() finishes, and kvmputkvm() can't return until asyncpfexecute() finishes:

WARNING: CPU: 8 PID: 251 at virt/kvm/kvmmain.c:1435 kvmputkvm+0x2d/0x320 [kvm] Modules linked in: vhostnet vhost vhostiotlb tap kvmintel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events asyncpfexecute [kvm] RIP: 0010:kvmputkvm+0x2d/0x320 [kvm] Call Trace: asyncpfexecute+0x198/0x260 [kvm] processonework+0x145/0x2d0 workerthread+0x27e/0x3a0 kthread+0xba/0xe0 retfromfork+0x2d/0x50 retfromforkasm+0x11/0x20 ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events asyncpfexecute [kvm] Call Trace: schedule+0x33f/0xa40 schedule+0x53/0xc0 scheduletimeout+0x12a/0x140 waitforcommon+0x8d/0x1d0 flushwork.isra.0+0x19f/0x2c0 kvmclearasyncpfcompletionqueue+0x129/0x190 [kvm] kvmarchdestroyvm+0x78/0x1b0 [kvm] kvmputkvm+0x1c1/0x320 [kvm] asyncpfexecute+0x198/0x260 [kvm] processonework+0x145/0x2d0 workerthread+0x27e/0x3a0 kthread+0xba/0xe0 retfromfork+0x2d/0x50 retfromforkasm+0x11/0x20

If kvmclearasyncpfcompletionqueue() actually flushes the workqueue, then there's no need to gift asyncpfexecute() a reference because all invocations of asyncpfexecute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as fput() won't do moduleput() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module.

Note that kvmcheckasyncpfcompletion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvmclearasyncpfcompletionqueue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvmarchasyncpagepresentqueued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just:

tracekvmasyncpfcompleted(addr, cr2orgpa);

kvmvcpuwakeup(vcpu);

mmput(mm);

and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables.

Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes flushwork() complain (kudos to whoever added that sanity check).

Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---

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

netfilter: nftsetpipapo: do not free live element

Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo:

addelem("00000000") timeout 100 ms ... addelem("0000000X") timeout 100 ms delelem("0000000X") <---------------- delete one that was just added ... addelem("00005000") timeout 100 ms

1) nftpipaporemove() removes element 0000000X Then, KASAN shows a splat.

Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element.

Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map.

The remove function does not work correctly if we have more than one element that share the same key.

This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation.

In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable.

The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer).

Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching.

Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element.

v2: avoid uneeded temporary variable (Stefano)

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

netfilter: nfconntrackh323: Add protection for bmp length out of range

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041723-CVE-2024-26851-4652@gregkh/T

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

bonding: fix xfrm realdev null pointer dereference

We shouldn't set realdev to NULL because packets can be in transit and xfrm might call xdodevoffloadok() in parallel. All callbacks assume realdev is set.

Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: errorcode(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsimipsecoffloadok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: kernel: ? die+0x1f/0x60 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ? pagefaultoops+0x142/0x4c0 kernel: ? douseraddrfault+0x65/0x670 kernel: ? kvmreadandresetapfflags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? excpagefault+0x7b/0x180 kernel: ? asmexcpagefault+0x22/0x30 kernel: ? nsimbpfuninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ? nsimipsecoffloadok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bondipsecoffloadok+0x7b/0x90 [bonding] kernel: xfrmoutput+0x61/0x3b0 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ippushpendingframes+0x56/0x80

A race condition was found in the Linux kernel's net/bluetooth device driver in conninfo{min,max}ageset() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.

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

bonding: fix null pointer deref in bondipsecoffloadok

We must check if there is an active slave before dereferencing the pointer.

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

netfilter: flowtable: initialise extack before use

Fix missing initialisation of extack in flow offload.

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

padata: Fix possible divide-by-0 panic in padatamthelper()

We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time.

[ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x8664 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: eventsunbound padatamthelper [ 10.017908] RIP: 0010:padatamthelper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] [ 10.018004] ? padatamthelper+0x39/0xb0 [ 10.018084] processonework+0x174/0x330 [ 10.018093] workerthread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] retfromfork+0x31/0x50 [ 10.018138] retfromforkasm+0x1a/0x30 [ 10.018147]

Looking at the padatamthelper() function, the only way a divide-by-0 panic can happen is when ps->chunksize is 0. The way that chunksize is initialized in padatadomultithreaded(), chunksize can be 0 when the minchunk in the passed-in padatamtjob structure is 0.

Fix this divide-by-0 panic by making sure that chunksize will be at least 1 no matter what the input parameters are.

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

sctp: Fix null-ptr-deref in reuseportaddsock().

syzbot reported a null-ptr-deref while accessing sk2->skreuseportcb in reuseportaddsock(). [0]

The repro first creates a listener with SOREUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener.

The second listen() calls reuseportaddsock() with the first listener as sk2, where sk2->skreuseportcb is not expected to be cleared concurrently, but the close() does clear it by reuseportdetachsock().

The problem is SCTP does not properly synchronise reuseportalloc(), reuseportaddsock(), and reuseportdetachsock().

The caller of reuseportalloc() and reuseport{add,detach}sock() must provide synchronisation for sockets that are classified into the same reuseport group.

Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead.

1. Two sockets call listen() concurrently 2. No socket in the same group found in sctpephashtable[] 3. Two sockets call reuseportalloc() and form two reuseport groups 4. Only one group hit first in sctprcvlookupendpoint() receives incoming packets

Also, the reported null-ptr-deref could occur.

TCP/UDP guarantees that would not happen by holding the hash bucket lock.

Let's apply the locking strategy to sctphashendpoint() and sctpunhashendpoint().

[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 RIP: 0010:reuseportaddsock+0x27e/0x5e0 net/core/sockreuseport.c:350 Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012 RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sctphashendpoint net/sctp/input.c:762 [inline] sctphashendpoint+0x52a/0x600 net/sctp/input.c:790 sctplistenstart net/sctp/socket.c:8570 [inline] sctpinetlisten+0x767/0xa20 net/sctp/socket.c:8625 syslistensocket net/socket.c:1883 [inline] syslisten+0x1b7/0x230 net/socket.c:1894 dosyslisten net/socket.c:1902 [inline] sesyslisten net/socket.c:1900 [inline] x64syslisten+0x5a/0x70 net/socket.c:1900 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIGRAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0 R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c R13: ---truncated---