Bluetooth: fix UAF in btacceptdequeue()

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

ASoC: codecs: simple-mux: Fix enum control bounds check

simplemuxcontrolput() rejects values greater than e->items, but enum control values are zero based. For the two-entry mux used by this driver, valid values are 0 and 1, so value 2 must be rejected as well.

Accepting e->items can store an invalid mux state, pass it to the GPIO setter, and pass it on to the DAPM mux update path where it is used as an index into the enum text array.

Use the same >= e->items check used by the ASoC enum helpers.

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

usb: gadget: net2280: Fix double free in probe error path

usbinitializegadget() installs gadgetrelease() as the release callback for the embedded gadget device. The struct net2280 instance is therefore released through gadgetrelease() when the gadget device's last reference is dropped.

The probe error path calls net2280remove(), which tears down the partially initialized device and drops the gadget reference with usbputgadget(). Calling kfree(dev) afterwards can free the same object again.

Drop the explicit kfree() and let the gadget device release callback handle the final free. This issue was found by a static analysis tool I am developing.

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

mm/damon/sysfs-schemes: delete tried region in regionsrmdirs()

DAMON sysfs maintains the DAMOS tried region directory objects via a linked list. When the user requests refresh of the directories, DAMON sysfs removes all the region directories first, and then generate updated regions directory on the empty space. The removal function (damonsysfsschemeregionsrmdirs()) only puts the kobj objects. Deletion of the container region object from the linked list is done inside the kobj release callback function.

If somehow the callback invocation is delayed, the list will contain regions list that gonna be freed. If the updated region directories creation is started in this situation, the list can be corrupted and use-after-free can happen.

Because the kobj objects are managed by only DAMON sysfs, the issue cannot happen in normal situation. But, such delays can be made on kernels that built with CONFIGDEBUGKOBJECTRELEASE. On the kernel, the issue can indeed be reproduced like below.

# damo start --damosaction stat # cd /sys/kernel/mm/damon/admin/kdamonds/0/ # for i in {1..10}; do echo updateschemestriedregions > state; done # dmesg | grep underflow [ 89.296152] refcountt: underflow; use-after-free.

Fix the issue by removing the region object from the list when decrementing the reference count.

Also update damossysfspopulateregiondir() to add the region object to the list only after the kobjectinitandadd() is success, so that fail of kobjectinitandadd() is not leaving the deallocated object on the list.

The issue was discovered [1] by Sashiko.

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

Input: elani2c - validate firmware size before use

Ensure that the firmware file is large enough to contain the expected number of pages and the signature (which resides at the end of the firmware blob) before accessing them to prevent potential out-of-bounds reads.

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

x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines

With CONFIGCALLDEPTHTRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function:

BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: <TASK> ? findheldlock ? excpagefault ? lockrelease ? x64sysclocknanosleep ? lockdephardirqsonprepare ? tracehardirqson x64sysclocknanosleep dosyscall64 ? excpagefault ? calldepthreturnthunk entrySYSCALL64afterhwframe ... Kernel panic - not syncing: Fatal exception

This small reproducer allows to easily trigger the crash:

# echo 'p x64sysclocknanosleep' > /sys/kernel/tracing/kprobeevents # echo 1 > /sys/kernel/tracing/events/kprobes/px64sysclocknanosleep0/enable # usleep 1

Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth:

sarq $5, %gs:x86calldepth(%rip)

This instruction matches the one inserted by the ftraceregscaller from ftrace64.S. This emitted code was likely working fine until the introduction of

59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PERCPUVAR()"):

it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address.

As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu x86calldepth value, otherwise the targeted address is wrong, leading to the page fault seen above.

Fix the %rip-relative displacement of the copied CALLDEPTHACCOUNT instruction (from ftraceregscaller) by calling textpokeapplyrelocation(), as it is done for example by the x86 BPF JIT compiler through x86calldepthemitaccounting(). This corrects both CALLDEPTHACCOUNT slots, in ftracecaller and ftraceregscaller.

[ bp: Massage. ]

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

KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use

As per the GHCB spec, when using GHCB v2+ require the software scratch area to reside in the GHCB's shared buffer. Note, things like Page State Change (PSC) requests rely on this behavior, as the guest can't provide a length when making the request, i.e. the size of the guest payload is bounded by the size of the shared buffer.

Failure to force usage of the GHCB, and a slew of other flaws, lets a malicious SNP guest corrupt host kernel heap memory, and leak host heap layout information.

setupvmgexitscratch() allocates a buffer via kvzalloc(exitinfo2), where exitinfo2 is guest-controlled. With exitinfo2=24, this yields a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer holds an 8-byte pschdr followed by 8-byte pscentry structs, so only entries[0] and entries[1] are in-bounds.

snpbeginpsc() validates endentry against VMGEXITPSCMAXCOUNT (253) but NOT against the actual buffer size:

idxend = hdr->endentry;

if (idxend >= VMGEXITPSCMAXCOUNT) { // checks 253, not buffer snpcompletepsc(svm, ...); return 1; }

for (idx = idxstart; idx <= idxend; idx++) { entrystart = entries[idx]; // OOB when idx >= 2

The guest sets endentry=10+, causing the host to iterate entries[2+] which are OOB into adjacent slab objects. For each OOB entry:

- The host reads 8 bytes (OOB READ / info leak oracle) - If the data passes PSC validation, snpcompleteonepsc() writes curpage = 1 or 512 into the entry (OOB WRITE, sev.c:3806) - If validation fails, the error response reveals whether adjacent memory is zero vs non-zero (information disclosure to guest)

The guest controls allocation size (exitinfo2), entry range (curentry/endentry), and can fire unlimited VMGEXITs to repeatedly hit different slab positions.

By exploiting the variety of bugs, a malicious SEV-SNP guest can: - OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure) - OOB write curpage bits into adjacent objects (heap corruption) - Trigger use-after-free conditions across VMGEXITs

E.g. with KASAN enabled, a single insmod of the PoC guest module produces 73 KASAN reports:

BUG: KASAN: slab-out-of-bounds in snpbeginpsc+0x126/0x890 Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199

BUG: KASAN: slab-out-of-bounds in snpbeginpsc+0x468/0x890 Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199

The buggy address belongs to the object at ffff888XXXXXXXXX which belongs to the cache kmalloc-cg-32 of size 32 The buggy address is located N bytes to the right of allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX)

Breakdown: 62 slab-out-of-bounds (reads + writes past allocation) 7 slab-use-after-free 4 use-after-free

All credit to Stan for the wonderful description and reproducer!

[sean: write changelog]

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

Bluetooth: L2CAP: use chan timer to close channels in cleanuplisten()

l2capchanclose() removes the channel from conn->chanl, which must be done under conn->lock. cleanuplisten() runs under the parent sklock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sklock order.

Instead of calling l2capchanclose() directly, schedule l2capchantimeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order.

The timer is only armed when chan->conn is still set: if it is already NULL, l2capconndel() has already processed this channel (l2capchandel + l2capsockteardowncb + l2capsockclosecb), so there is nothing left to do. If l2capconndel() races in after the timer is armed, clearchantimer() inside l2capchandel() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.

drm/i915/gem: Fix phys BO pread/pwrite with offset

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

rust: arm64: set uwtable llvm module flag for CONFIGUNWINDTABLES

Due to a rustc bug [1] the -Cforce-unwind-tables=y flag only emits the uwtable annotation for functions, but not for the module. This means that compiler-generated functions such as 'asan.modulector' do not receive the uwtable annotation.

When CONFIGUNWINDPATCHPACINTOSCS is enabled, this leads to boot failures because the dwarf information emitted for the kasan constructors is wrong, which causes the SCS boot patching code to patch the constructor in an illegal manner. Specifically, the paciasp instruction is patched, but the autiasp instruction is not. This mismatch leads to a crash when the constructor is called during boot.

================================================================== BUG: KASAN: global-out-of-bounds in dobasicsetup+0x4c/0x90 Read of size 8 at addr ffffffe3cc7eb488 by task swapper/0/1

Specifically the faulting instruction is the (fn)() to invoke the constructor in doctors() of the init/main.c file.

Once the fix lands in rustc, this flag can be made conditional on the rustc version. Note that passing the flag on a rustc with the fix present has no effect.

[ The fix [1] has landed for Rust 1.98.0 (expected release on 2026-08-20).

Thus add a version check as discussed.

- Miguel ]

[ Adjusted link and comment. - Miguel ]

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

KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation

walks1() and kvmwalknesteds2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, kvmats12() and kvmfinds1desclevel() call into the respective walkers without taking kvm->srcu.

Fix by acquiring kvm->srcu prior to the table walk in both instances.

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

Bluetooth: ISO: Fix a use-after-free of the hciconn pointer

In isosockrebindbc(), the bis pointer is cached, then the socket lock is dropped: bis = isopi(sk)->conn->hcon; / Release the socket before lookups since that requires hcidevlock which shall not be acquired while holding socklock for proper ordering. / releasesock(sk); hcidevlock(bis->hdev);

During the unlocked window, could a concurrent close() destroy the connection and free the bis structure, causing hcidevlock(bis->hdev) to access memory after it is freed, fix this by using the hdev reference which was safely acquired via isoconngethdev().

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

ipv6: mcast: Fix use-after-free when processing MLD queries

When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskbmaypull() calls, leading to a use-after-free [1].

Fix by copying the multicast group address when the packet is initially parsed.

[1] BUG: KASAN: slab-use-after-free in mldquerywork (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118

Workqueue: mld mldquerywork Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) printaddressdescription.constprop.0 (mm/kasan/report.c:378) printreport (mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:595) mldquerywork (net/ipv6/mcast.c:1512) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) </TASK>

[...]

Freed by task 118: kasansavestack (mm/kasan/common.c:57) kasansavetrack (mm/kasan/common.c:78) kasansavefreeinfo (mm/kasan/generic.c:584) kasanslabfree (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskbexpandhead (net/core/skbuff.c:2335) pskbpulltail (net/core/skbuff.c:2878 (discriminator 4)) mldquerywork (net/ipv6/mcast.c:1495 (discriminator 1)) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

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

tee: optee: prevent use-after-free when the client exits before the supplicant

Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request.

If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free.

Serialise access to the request with supp->mutex:

Hold supp->mutex in opteesupprecv() and opteesuppsend() while looking up and touching the request. Let opteesuppthrdreq() notice that the client has terminated and signal opteesuppsend() accordingly.

With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.

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

erofs: fix use-after-free on sbi->syncdecompress

zerofsdecompresskickoff() can race with filesystem unmount, causing a use-after-free on sbi->syncdecompress.

When I/O completes, zerofsendio() calls zerofsdecompresskickoff() to queue zerofsdecompressqueuework() asynchronously. Then, after all folios are unlocked, unmount workflow can proceed and sbi will be freed before accessing to sbi->syncdecompress.

Thread (unmount) I/O completion kworker queuework zerofsdecompressqueuework (all folios are unlocked) cleanupmnt .. erofskillsb erofssbfree kfree(sbi) access sbi->syncdecompress // UAF!!

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

ipvs: clear the svc scheduler ptr early on edit

ipvseditservice() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->scheddata is already freed after RCU grace period.

Fix it by clearing the ptr early in ipvsunbindscheduler(), before the doneservice method schedules any RCU callbacks.

Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.

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

netfilter: conntrackirc: fix possible out-of-bounds read

When parsing fails after we've matched the command string we should bail out instead of trying to match a different command.

This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.

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

netfilter: nftct: bail out on template ct in get eval

I noticed this issue while looking at a historic syzbot report [1].

A rule like the one below is enough to trigger the bug:

table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } }

The first expression attaches a per-cpu template ct via nftctsetzoneeval() (nfcttmplalloc -> kzalloc, tuple is all zero, nfctl3num(ct) == 0). The next expression then calls nftctgeteval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFTREG3215 this overflows past struct nftregs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers.

Reject template ct at the eval entry and in nftctgetfasteval(), mirroring the check nftctseteval() already has. Additionally, bound the address copy in NFTCTSRC / NFTCTDST by priv->len instead of by nfctl3num(ct): nfctgettuple() zeroes the tuple before pkttotuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack.

[1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c

dm cache policy smq: check allocation under invalidate lock

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

net/sched: actapi: use RCU with deferred freeing for action lifecycle

When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.

Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:

0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfarefcnt) <-- ouch, UAF p points to freed memory

This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a callrcu() in the delete path to defer the final kfree().

Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfreercu().

Let's illustrate the new restored code path:

0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period

After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.

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

l2tp: pppol2tp: hold reference to session in pppol2tpioctl()

pppol2tpioctl() read sock->sk->skuserdata directly without any locks or reference counting. If a controllable sleep was induced during copyfromuser() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tpsessionclose() asynchronously. This frees the l2tpsession structure via the l2tpsessiondelwork workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF).

Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tpsocktosession(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tpsessionput() is cleanly called on all return paths to drop the reference.

To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sockdoioctl()).

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

ipv6: anycast: insert aca into global hash under idev->lock

syzbot reported a splat [1]: a slab-use-after-free in ipv6chkacastaddr(), which walks the global inet6acaddrlst[] hash under RCU and dereferences a struct ifacaddr6 that has already been freed while still linked in the hash, so a later reader walks into a dangling node.

In ipv6devacinc() the aca is allocated with refcount 1, then acaget() bumps it to 2 to keep it alive across the unlocked region. It is published to idev->aclist under idev->lock, but ipv6addacaddrhash() runs after writeunlockbh(). A concurrent teardown (ipv6acdestroydev() from addrconfifdown(), under RTNL) can slip into that window:

CPU0 ipv6devacinc CPU1 ipv6acdestroydev (RTNL) ------------------------------ ------------------------------------ acaalloc() refcnt 1 acaget() refcnt 2 writelockbh(idev->lock) add aca to aclist writeunlockbh(idev->lock) writelockbh(idev->lock) pull aca off aclist writeunlockbh(idev->lock) ipv6delacaddrhash(aca) hlistdelinitrcu() is a no-op, aca is not in the hash yet acaput() refcnt 2->1 ipv6addacaddrhash(aca) aca now inserted into the hash acaput() refcnt 1->0 callrcu(acafreercu) -> kfree(aca)

The hash removal becomes a no-op because the insertion has not happened yet, so once CPU0 inserts and drops the last reference, the aca is freed while still linked in inet6acaddrlst[], and readers dereference freed memory after the slab slot is reused.

This window opened once RTNL stopped serializing the join path against device teardown. Move ipv6addacaddrhash() inside the idev->lock section so the aclist and hash insertions are atomic with respect to teardown: a racing remover now either misses the aca entirely or finds it in both lists.

acaddrhashlock is now nested under idev->lock, which is acquired in softirq context, so switch all acaddrhashlock sites to spinlockbh() to avoid the irq lock inversion reported in [2].

[1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a [2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/

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

Bluetooth: RFCOMM: hold listener socket in rfcommconnectind()

rfcommgetsockbychannel() scans rfcommsklist under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcommconnectind() then locks the listener, queues a child socket on it, and may notify it after unlocking it.

The buggy scenario involves two paths, with each column showing the order within that path:

rfcommconnectind(): listener close: 1. Find parent in 1. close() enters rfcommgetsockbychannel() rfcommsockrelease(). 2. Drop rfcommsklist.lock 2. rfcommsockshutdown() without pinning parent. closes the listener. 3. Call locksock(parent) and 3. rfcommsockkill() btacceptenqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call skstatechange().

If close wins the race, parent can be freed before rfcommconnectind() reaches locksock(), btacceptenqueue(), or the deferred-setup callback.

Take a reference on the listener before leaving rfcommsklist.lock. After locksock() succeeds, recheck that it is still in BTLISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use.

KASAN reported a slab-use-after-free in locksocknested() from rfcommconnectind(), with the freeing stack going through rfcommsockkill() and rfcommsockrelease().

Bluetooth: MGMT: validate advertising TLV before type checks

Bluetooth: RFCOMM: validate skb length in MCC handlers

Bluetooth: bnep: reject short frames before parsing

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

xsk: cache csumstart/csumoffset to fix TOCTOU in xskskbmetadata()

The TX metadata area resides in the UMEM buffer which is memory-mapped and concurrently writable by userspace. In xskskbmetadata(), csumstart and csumoffset are read from shared memory for bounds validation, then read again for skb assignment. A malicious userspace application can race to overwrite these values between the two reads, bypassing the bounds check and causing out-of-bounds memory access during checksum computation in the transmit path.

Fix this by reading csumstart and csumoffset into local variables once, then using the local copies for both validation and assignment.

Note that other metadata fields (flags, launchtime) and the cached csum fields may be mutually inconsistent due to concurrent userspace writes, but this is benign: the only security-critical invariant is that each field's validated value is the same one used, which local caching guarantees.

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

net: airoha: Fix use-after-free in metadata dst teardown

airohametadatadstfree() runs metadatadstfree() which frees the metadatadst with kfree() immediately, bypassing the RCU grace period. In the RX path, skbdstsetnoref() sets a non-refcounted pointer from the skb to the metadatadst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadatadstfree() calls kfree() directly, an use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadatadstfree() with dstrelease() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via callrcuhurry(), ensuring all RCU readers have completed before the memory is freed.

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

ipv4: restrict IPOPTSSRR and IPOPTLSRR options

This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAPNETRAW capability.

This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information.

While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths.

RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.

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

VFS: fix possible failure to unlock in nfsd4createfile()

atomiccreate() in fs/namei.c drops the reference to the dentry when it returns an error. This behaviour was imported into dentrycreate() so that it will drop the reference if an error is returned from atomiccreate(), though not if vfscreate() returns an error (in the case where ->atomiccreate is not supported).

The caller - nfsd4createfile() - is made aware of this by checking path->dentry, which will either be a counted reference to a dentry, or an error pointer.

However the change to use startcreating()/endcreating() (which landed shortly before the dentrycreate() change landed, though was likely developed around the same time) means that nfsd4createfile() needs a valid dentry so that it can unlock the parent.

The net result is that if NFSD exports a filesystem which uses ->atomiccreate, and if a call to ->atomiccreate returns an error, then nfsd4createfile() will pass an error pointer to endcreating() and the parent will not be unlocked.

Fix this by changing dentrycreate() to make sure path->dentry is always a valid dentry, never an error-pointer. The actual error is already returned a different way.

Note that if ->atomiccreate() returns a different dentry (which may not be possible in practice) we are guaranteed (because it is only ever provided by dspliacealias()) that it will have the same dparent and so it will have the same effect when passed to endcreating().