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

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:

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:

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:

kobjectuevent: Fix OOB access within zapmodaliasenv()

zapmodaliasenv() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove.

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

netfilter: nftables: prefer nftchainvalidate

nftchainvalidate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFTJUMPSTACKSIZE).

It also follows maps via ->validate callback in nftlookup, so there appears no reason to iterate the maps again.

nftablescheckloops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s.

This also fixes a crash bug. Old loop detection code can result in unbounded recursion:

BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..]

with a suitable ruleset during validation of register stores.

I can't see any actual reason to attempt to check for this from nftvalidateregisterstore(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph.

For nf-next it might make sense to either remove it or make this depend on table->validatestate in case we could catch an error earlier (for improved error reporting to userspace).

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

r8169: Fix possible ring buffer corruption on fragmented Tx packets.

An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dmaunmapsingle() with a null address.

This was caused by rtl8169startxmit() not noticing changes to nrfrags which may occur when small packets are padded (to work around hardware quirks) in rtl8169tsocsumv2().

To fix this, postpone inspecting nrfrags until after any padding has been applied.

VMware Tools contains a SAML token signature bypass vulnerability. A malicious actor that has been granted Guest Operation Privileges https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-6A952214-0E5E-4CCF-9D2A-90948FF643EC.html in a target virtual machine may be able to elevate their privileges if that target virtual machine has been assigned a more privileged Guest Alias https://vdc-download.vmware.com/vmwb-repository/dcr-public/d1902b0e-d479-46bf-8ac9-cee0e31e8ec0/07ce8dbd-db48-4261-9b8f-c6d3ad8ba472/vim.vm.guest.AliasManager.html .

open-vm-tools contains a file descriptor hijack vulnerability in the vmware-user-suid-wrapper. A malicious actor with non-root privileges may be able to hijack the /dev/uinput file descriptor allowing them to simulate user inputs.