IBM Aspera Faspex 5.0.0 through 5.0.19 could allow an authorized user to craft a specific message to bypass user authorization and gain full administrative privileges.

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in ASP.NET Core. This advisory provides guidance on updating affected applications and components.

SignalR connections are not consistently bound to the identity negotiated at connection establishment, allowing injected messages to execute Hub invocations as the victim.

Announcement

Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/504

CVSS Details

- Version: 3.1 - Severity: Critical - Score: 9.0 (base score) - Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C - Weakness: CWE-863

Affected Platforms

- Platforms: Windows, Linux, macOS - Architectures: All

<a name="affected-packages"></a>Affected Packages

The tables list affected version ranges and fixed package versions. Runtime and standalone deliveries are listed separately.

ASP.NET Core 2.3 - standalone packages

Package | Affected version | Patched version --- | --- | --- Microsoft.AspNetCore.Http.Connections | >= 1.2.0, <= 1.2.13 | 1.2.14

.NET 8.0 - affected runtime packages

Package | Affected version | Patched version --- | --- | --- Microsoft.AspNetCore.App.Runtime.linux-arm | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.linux-arm64 | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.linux-musl-arm | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.linux-musl-arm64 | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.linux-musl-x64 | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.linux-x64 | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.osx-arm64 | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.osx-x64 | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.win-arm64 | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.win-x64 | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34 Microsoft.AspNetCore.App.Runtime.win-x86 | >= 8.0.0-preview.1.23112.2, <= 8.0.33 | 8.0.34

.NET 9.0 - affected runtime packages

Package | Affected version | Patched version --- | --- | --- Microsoft.AspNetCore.App.Runtime.linux-arm | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.linux-arm64 | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.linux-musl-arm | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.linux-musl-arm64 | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.linux-musl-x64 | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.linux-x64 | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.osx-arm64 | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.osx-x64 | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.win-arm64 | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.win-x64 | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23 Microsoft.AspNetCore.App.Runtime.win-x86 | >= 9.0.0-preview.1.24081.5, <= 9.0.22 | 9.0.23

.NET 10.0 - affected runtime packages

Package | Affected version | Patched version --- | --- | --- Microsoft.AspNetCore.App.Runtime.linux-arm | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.linux-arm64 | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.linux-musl-arm | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.linux-musl-arm64 | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.linux-musl-x64 | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.linux-x64 | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.osx-arm64 | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.osx-x64 | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.win-arm64 | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.win-x64 | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15 Microsoft.AspNetCore.App.Runtime.win-x86 | >= 10.0.0-preview.1.25120.3, <= 10.0.14 | 10.0.15

.NET 11.0 - affected runtime packages

Package | Affected version | Patched version --- | --- | --- Microsoft.AspNetCore.App.Runtime.linux-arm | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.linux-arm64 | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.linux-musl-arm | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.linux-musl-arm64 | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.linux-musl-x64 | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.linux-x64 | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.osx-arm64 | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.osx-x64 | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.win-arm64 | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.win-x64 | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0 Microsoft.AspNetCore.App.Runtime.win-x86 | >= 11.0.0-preview.1.26104.118, <= 11.0.0-rc.3.26522.148 | 11.0.0

Advisory FAQ

<a name="how-affected"></a>How do I know if I am affected?

Check the deployed runtime and application package versions against the affected ranges above. Self-contained applications include their own runtime; updating a machine-wide runtime does not replace it.

<a name="how-fix"></a>How do I fix the issue?

Install the applicable runtime or update each independently referenced package to the fixed version above. After updating standalone packages, rebuild and redeploy affected applications, including framework-dependent applications; restarting alone does not replace app-local packages. Restart applications. Rebuild and redeploy self-contained applications; updating a machine-wide runtime does not replace their embedded runtime. An SDK update alone does not update an application's standalone package references.

Other Information

Reporting Security Issues

If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the MSRC Researcher Portal. Further information can be found in the MSRC Report an Issue FAQ.

Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

External Links

CVE-2026-114146

Acknowledgements

- Mika Vehns with MIVE GmbH - Lucas Gabriel - hsuan0223x - Mariusz Maik - Pocas (Jeongwon Jo) - Grace Chapel - Jacob Keith with Keith Systems - Weeraphat Srisutham - Kevin Gosse - Artur Stetsko - Yudai Shibata - 71C4 - Attila Csatadi of ZeroDayBugs.com - Vu Van Tien ( @n0Be3r )

Revisions

V1.0 (November 10, 2026): Advisory published.

Insufficient validation of length fields in the GNSS firmware loader can result in kernel‑memory corruption.

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

wifi: p54: validate firmware record lengths

The p54 firmware parser accesses component ID and component version records without checking that their lengths cover the fields being read. A malformed record can therefore make the parser read past the record.

Validate the component ID and component version record lengths before accessing their data. The descriptor record is also checked against the shortest descriptor length found in the supported firmware images.

Reject descriptor values that underflow the RX offset or produce an empty RX range before updating the driver state.

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

scsi: libiscsi: Validate the ITT reflected in a Reject PDU

A Reject PDU carries a copy of the header it rejects, and iscsihandlereject() takes the ITT out of that copy to find the task to clean up:

memcpy(&rejectedpdu, data, sizeof(struct iscsihdr)); ... task = iscsiitttotask(conn, rejectedpdu.itt);

That value is whatever the target put there. iscsiitttotask() bounds the index against cmdsmax and checks nothing else, so any task in the pool can be named, and iscsinopoutrsp() then completes it.

An index that has never been used gives a NULL task->conn: the pool is zeroed at session setup and conn is assigned only when a task is allocated. If the task was used and returned, iscsicompletetask() hits its WARNONONCE(task->state == ISCSITASKFREE) and the refcount underflows. An in-flight SCSI command is completed as successful - a 1 MiB read returned 1048576 with none of its buffer written and no warning.

Validate the reflected ITT the way iscsiitttoctask() validates a command ITT, and require the task to be in flight and not a SCSI command.

[ 6.248477] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.249357] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.249951] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.250718] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 6.251616] RIP: 0010:iscsinopoutrsp.constprop.0+0x46/0x160 [ 6.252043] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.252813] RSP: 0018:ffff88806c907b80 EFLAGS: 00010206 [ 6.253042] RAX: dffffc0000000000 RBX: ffff88800607e000 RCX: ffffffff8d571a25 [ 6.253345] RDX: 000000000000000c RSI: ffff88806c907c38 RDI: 0000000000000060 [ 6.253642] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff235a504 [ 6.253947] R10: 0000000000000003 R11: 7463656e6e6f6320 R12: 0000000000000000 [ 6.254251] R13: 0000000000000000 R14: ffff88806c907c38 R15: 0000000000000000 [ 6.254549] FS: 0000000000000000(0000) GS:ffff8880d95bc000(0000) knlGS:0000000000000000 [ 6.254887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.255140] CR2: 00007fc393e8ffc0 CR3: 0000000005252006 CR4: 0000000000770ef0 [ 6.255439] PKRU: 55555554 [ 6.255564] Call Trace: [ 6.255674] <IRQ> [ 6.255768] iscsicompletepdu+0x18bf/0x22a0 [ 6.256733] iscsicompletepdu+0x54/0xa0 [ 6.256905] iscsitcpdatarecvdone+0xf4/0x250 [ 6.257103] iscsitcprecvskb+0x31e/0xec0 [ 6.257680] iscsiswtcprecv+0x12f/0x390 [ 6.258061] tcpreadsock+0x1ab/0x810 [ 6.258853] iscsiswtcpdataready+0x18b/0x510 [ 6.259808] tcpdataqueue+0x1f13/0x4cd0 [ 6.260567] tcprcvestablished+0x8a5/0x3a00 [ 6.261931] tcpv4dorcv+0x449/0x960 [ 6.262269] tcpv4rcv+0x2245/0x3bc0

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

scsi: libiscsi: Reject a negative task index from parsepduitt

A transport that implements parsepduitt hands libiscsi an index taken from the PDU, and both lookups bound it from above only:

if (i >= session->cmdsmax)

i and cmdsmax are both int, so a negative index passes and session->cmds[i] is read from before the array.

be2iscsi produces one. beiscsiparsepdu() assigns the raw tag,

index = (int)itt;

and beiscsicompletepdu() forwards an unsolicited NOP-In from the hardware async ring without replacing its ITT, so the value is the target's. It also reports the session's own age rather than the one in the tag, which leaves the age comparison in iscsiverifyitt() with nothing to reject.

Bound the index from below in both lookups.

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

net/mlx5e: Prevent stale XSK buffer release on refill retry

When an XDP redirect to an AFXDP socket fails because its RX ring is full, the XSK core frees the buffer. During the subsequent batched refill of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before allocating a replacement. If that refill succeeds only partially, a WQE left without a replacement retains its old buffer pointer.

The buffer can meanwhile be allocated to another WQE. A later refill retry can then free the live buffer through the stale pointer and publish the same UMEM frame twice.

Mark the WQE as released immediately after the driver-side free. The flag is already cleared when a replacement buffer is assigned, so refill retries no longer release stale pointers.

The failure is silent and produces no kernel warning or splat. A standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914 packets in 4.094 seconds, with 4,542 xdprxringfull events and 64 ownership/double-publication errors. With this change it processed 356,904,225 packets in 30 seconds despite 571,405 xdprxringfull events, with no ownership or data errors.

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

net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry

With AFXDP on a striding RQ, mlx5e defers releasing XSK buffers until an MPWQE is refilled. If XSK allocation then returns -ENOMEM, actualwqhead is not advanced and a later NAPI poll retries the same WQE.

mlx5efreerxmpwqe() leaves each released slot marked as releasable. On retry it can therefore call xskbufffree() again through stale pointers after the frames have returned to the XSK pool and been reallocated.

Set all skipreleasebitmap bits in the common error path of mlx5exskallocrxmpwqe(). This matches mlx5eallocrxmpwqe(). A successful allocation already clears the bitmap after replacing every buffer, so retries become idempotent without changing the success path.

Fault injection forced three consecutive failures for one selected MPWQE. Both an early allocation failure and a partial 8-of-16-buffer unwind released the original 16 XSK buffers only once. Each error left a full bitmap, the following NAPI retry skipped the release, and a later successful allocation cleared it. A 20-second AFXDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings.

btrfs: fix xattr replace when multiple xattrs are packed in the same item

Summary

Out-of-bounds Write vulnerability in the bundled Brotli decoder in yjh0502 erl-brotli allows an attacker who supplies a crafted Brotli-compressed stream to brotli:decode/1 to corrupt decoder state memory, disclose memory contents, crash the Erlang VM, or potentially execute code.

erl-brotli compiles its own copy of the Google Brotli C sources under csrc into a NIF, and brotlidecoderdecompressstream in csrc/brotlinif.c hands the input to BrotliDecoderDecompressStream. In csrc/dec/decode.c, DecodeBlockTypeAndLength returns false for a block switch in a category with at most one block type, and the non-streaming callers DecodeLiteralBlockSwitch, DecodeCommandBlockSwitch and DecodeDistanceBlockSwitch discard that result, so decoding continues with inconsistent state. The decoder runs inside a NIF, so memory corruption or a crash takes down the whole VM rather than the calling process. Because the package carries its own copy of the library, the Brotli version installed on the host does not matter.

This issue affects brotli: from 0.3.0 before 0.3.4.

Impact

An attacker who can get an application to decode a Brotli stream they control, for example an HTTP client that decompresses Content-Encoding: br responses with this package, can crash the Erlang VM and potentially run code inside it.

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

tipc: prevent GCM nonce reuse on peer key changes

TIPC can encrypt traffic between nodes using a different transmit key for each node. In this mode, the AES-GCM nonce for a packet sent to a known peer consists of a 32-bit prefix (a per-key salt XOR the peer's address) followed by a 64-bit counter. That counter is stored in the peer's RX crypto object. When the peer reports a change in which key it uses to receive packets, TIPC resets this counter. The sender can still be using the same TX key and salt, so subsequent packets reuse earlier nonces. This nonce reuse breaks confidentiality and exposes GCM's authentication key. This makes forgeries trivial: an attacker can exploit CTR malleability to alter captured ciphertexts and use the recovered authentication key to compute a valid tag for the modified ciphertext, under the same key and nonce.

Use the TX key's existing aead->seqno counter instead. All encryptions using that key object share the same atomic counter, so concurrent encryptions get distinct nonce counter values. The counter survives key activation and peer reconnection, and peer key-status reports cannot reset it. This prevents those transitions from causing nonce reuse while the same TX key remains installed.

The nonce format is unchanged, and receivers do not require consecutive counter values, so sharing the counter across peers remains compatible with existing receivers. A pre-existing check still invokes key revocation in the unlikely event that the counter wraps to zero.

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

nvmet-auth: fix out-of-bounds write in nvmetauthchallenge()

nvmetauthchallenge() receives its output buffer as a void pointer. sizeof(d) therefore evaluates to one with GCC and undercounts the fixed challenge header by 15 bytes. A short AUTHRECEIVE buffer can pass the check before the challenge is copied past the end of its allocation.

Use the typed challenge pointer when calculating the response size.

BUG: KASAN: slab-out-of-bounds in nvmetexecuteauthreceive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) Write of size 32 by task kworker/1:1H/64 Workqueue: nvmettcpwq nvmettcpiowork Call Trace: nvmetexecuteauthreceive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) nvmettcptryrecvpdu (drivers/nvme/target/tcp.c:1119 drivers/nvme/target/tcp.c:1243) nvmettcpiowork (drivers/nvme/target/tcp.c:1350 drivers/nvme/target/tcp.c:1382 drivers/nvme/target/tcp.c:1445) processonework (kernel/workqueue.c:3322) workerthread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) The buggy address is located 16 bytes inside of allocated 33-byte region [ffff888000554e80, ffff888000554ea1) Kernel panic - not syncing: KASAN: paniconwarn set ...

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

net: gue: reject invalid REMCSUM offsets

The REMCSUM option carries an absolute checksum start and checksum field offset. gueremcsum() passes them to skbremcsumprocess(), whose partial path stores offset - start in the u16 skb->csumoffset variable. If offset is less than start, this underflows.

A forwarded packet can retain CHECKSUMPARTIAL and reach a NETIFFHWCSUM driver which trusts the metadata, leading skbcopyandcsumdev() to write two bytes about 64 KiB beyond the destination buffer.

Reject reversed tuples in validategueflags(), after the existing length validation, so all GUE parsers enforce the ordering in one place.

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

net: stmmac: clear stale buf->page after recycling on skb build failure

In stmmacrx(), when napibuildskb() fails the descriptor page is recycled back to the page pool with pagepoolrecycledirect(), but buf->page is left pointing at the recycled page, unlike every other consumption site in the function which clears the pointer after handing the page away.

With the stale pointer stmmacrxrefill() skips the replacement allocation and programs the already-recycled page back into the RX descriptor.

Clear buf->page on the napibuildskb() failure path to keep the buffer lifecycle consistent with the other consumption sites.

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

ipv4: free inetopt and ireqopt after an RCU grace period

tcpv4synrecvsock() transfers ownership of ireq->ireqopt to the child socket (newinet->inetopt) without copying it.

Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcpcheckreq(). tcpv4sendsynack() and inetcskroutereq() read ireq->ireqopt under rcureadlock() only, and ipbuildandsendpkt() and ipoptionsbuild() then read opt->optlen twice.

Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inetcskreqskqueuedrop() calls timerdeletesync() before the child can be freed.

Since commit 079096f103fa ("tcp/dccp: install synrecv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCKRCUFREE, and inetsockdestruct() frees inetopt with a plain kfree(), leading to a use-after-free in ipoptionsbuild().

A similar issue exists with request socket migration (net.ipv4.tcpmigratereq=1, or a BPFSKREUSEPORTSELECTORMIGRATE program). reqsktimerhandler() clones the request socket with inetreqskclone(), so that the old request socket and its clone share the same ireqopt, then reqskmigratereset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcpv4synrecvsock()) when the clone is freed, and tcpv4reqskdestructor() also uses a plain kfree().

Readers already use RCU, and other paths replacing inetopt (doipsetsockopt(), cipsov4socksetattr()...) already use kfreercu(). Use kfreercu() in inetsockdestruct() and tcpv4reqskdestructor() as well.

IPv6 is not affected by the first issue, because tcpv6synrecvsock() duplicates the options. tcpv6reqskdestructor() has the same migration issue with ipv6opt, which is only set by CALIPSO. This will be addressed in a separate patch.

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

xfrm: fix compat ALLOCSPI request use-after-free

xfrmstatenetlink() builds the ALLOCSPI response with dumponestate(), which already calls alloccompat() with the response skb and header.

xfrmallocuserspi() then calls alloccompat() again, but passes the original request skb and its header. For a compat request, the translator therefore interprets the 228-byte compat xfrmuserspiinfo as the 232-byte native layout and reads four bytes past the declared payload. It also publishes the translated child through the request's fraglist.

A multicast clone of the request shares skbsharedinfo and can observe that child. xfrmuserrcvmsg() frees it after the request handler returns, racing a compat receiver which may still be copying from it and resulting in a use-after-free.

Remove the redundant conversion. The response keeps its correct compat translation from dumponestate(), and no child is attached to the inbound request.

esp: downgrade zerocopy managed frags before mutating skb frags

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

RDMA/rxe: Fix integer overflow in mrcheckrange() leading to OOB access

mrcheckrange() validates that [iova, iova+length) falls within the registered MR range using wraparound-prone arithmetic:

if (iova < mr->ibmr.iova || iova + length > mr->ibmr.iova + mr->ibmr.length)

A remote peer can craft an RDMA-Write/Read RETH so that iova + length wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the check. rxemriovatoindex() then computes a huge index (int idx, only guarded by WARNON) and rxemrcopyxarray() dereferences mr->pageinfo[huge], causing an out-of-bounds read/write and a kernel oops that is triggerable by an unauthenticated remote peer.

Rewrite the check in overflow-safe form; the first two clauses guarantee that the subsequent subtractions do not underflow:

if (iova < mr->ibmr.iova || length > mr->ibmr.length || iova - mr->ibmr.iova > mr->ibmr.length - length)

With the fix, mrcheckrange() returns -EINVAL for the crafted iova and the responder reports REMOTEACCESSERROR instead of triggering the OOB.

firmware: armscpi: reject DVFS OPP count above MAXDVFSOPPS

clk: scpi: bound-check DVFS index in scpidvfsrecalcrate

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

RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted

The client borrows shared CQ credits in the ADDRRESOLVED handler via ibcqpoolget(), before the peer is connected. createcm() can return -ERESTARTSYS from waiteventinterruptibletimeout() without destroying the CM ID. The initconns() and stop-and-destroy paths then call destroyconcqqp() while cq is still NULL (no PUT) and only afterwards rdmadestroyid().

CMA serializes the handler against rdmadestroyid() with handlermutex, but that does not order the GET against destroyconcqqp(). If ADDRRESOLVED has already passed the DESTROYING check, it can take conmutex, GET credits, and then lose the con to kfree. Device unregister later hits WARNON(cq->cqeused) in ibcqpoolcleanup().

Set a per-connection flag under conmutex before CQ/QP teardown so a racing ADDRRESOLVED cannot borrow credits after teardown has begun.

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

wifi: virtwifi: free skb when disconnected

When the simulated link is disconnected, virtwifistartxmit() returns NETXMITDROP without freeing the skb. devhardstartxmit() treats this return value as consumed, so every packet sent while disconnected leaks its skb.

Free the skb before returning the drop status.

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

wifi: libipw: reject too-short association responses

libipwhandleassocresp() reads the capability, status and aid fields of the 30-byte association response prefix and then computes the information element length as

stats->len - sizeof(frame)

stats->len is a u16 and sizeof() has type sizet, so the subtraction is evaluated as sizet and wraps instead of going negative. Truncating that to the u16 length parameter of libipwparseinfoparam() turns a frame shorter than the fixed fields into a length near 64 KiB, and the parser then reads past the receive buffer.

Both the ipw2100 and ipw2200 management receive paths reach this function having established only that the frame carries the generic 24-byte three-address header.

Reject the frame before any fixed field is touched.

Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device.

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

wifi: cfg80211: check IP header size in cfg80211classify8021d()

A frame that looks like IP can be transmitted, but be too short, so the DS field is read incorrectly:

BUG: KMSAN: uninit-value in cfg80211classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 cfg80211classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 ieee80211selectqueue+0x37a/0x9e0 net/mac80211/wme.c:180 ieee80211subifstartxmit+0x60f/0x1d90 net/mac80211/tx.c:4304 ieee80211subifstartxmit+0xa8/0x6d0 net/mac80211/tx.c:4538 ... packetsendmsg+0x9173/0xa2a0 net/packet/afpacket.c:3108

Use skbheaderpointer() like the MPLS case.

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

wifi: cfg80211: only group hidden BSSes with beacon entries

When a probe response for an unknown BSS comes in, cfg80211bssupdate() looks for an existing entry with the same BSSID and a hidden (zero-length or NUL-filled) SSID, and if it finds one it groups them, using the beacon IEs from the existing entry.

But that could find another entry without a beacon, if it was also from a probe response (with SSID), so there's a group without beacon elements.

If a beacon with a hidden SSID for that BSSID arrives later, cfg80211combinebsses() goes looking for the probe response entries that belong to it - i.e. entries with the same BSSID and channel that have no beacon IEs - and finds those two. They are already grouped with each other, so it hits its

WARNONONCE(bss->pub.hiddenbeaconbss) WARNONONCE(!listempty(&bss->hiddenlist))

which are there because an entry without beacon elements is not supposed to be part of a group yet.

Only combine entries when a beacon was already received, ones that are kept separate will be combined when a beacon arrives.

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

wifi: cfg80211: don't filter by BSS type when removing stale entries

When an assoc AP switches to a channel that already has a BSS entry, cfg80211updateassocbssentry() removes that entry before rehashing the real one, since the two would otherwise collide in the BSS rbtree.

The lookup for that entry also required it to match the connection's BSS type, so an entry advertising e.g. the IBSS capability bit was left in place, and the following cfg80211rehashbss() then ran into it:

WARNON(!cmp)

Changing the type shouldn't really happen, but can be triggered by a rogue AP/device, so drop the check and remove any entries matching the comparison.

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

wifi: mac80211: don't offload TC setup on APVLAN interfaces

APVLAN interfaces are purely virtual, so don't try to offload TC setup to drivers. We can't really use the AP interface either since we may not know it all the time, and it could technically even change.

Just reject the TC offload so things get done in software.

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

RDMA/siw: Bound fragmented header copies by the remaining length

siwgethdr() can receive an extended DDP/RDMAP header across more than one TCP callback. The first callback may receive most of the header, while the next one still limits the copy to hdrlen - MINDDPHDR instead of the number of missing bytes. This makes the destination move past the end of the header and overwrite the receive state, including fpdupartrcvd. A later callback can then use a negative fpdupartrcvd value as a copy offset, which creates an OOB write.

Use the number of header bytes already received when calculating the next copy length.

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

netfilter: nftnat: fully initialise newaddr in netmap setup

nftnatsetupnetmap() builds the mapped address in an on-stack union nfinetaddr. For an IPv4 mapping it writes only the 4-byte .ip member and the loop runs a single 32-bit iteration, but it then copies the whole 16-byte union into range->minaddr and range->maxaddr, so the upper 12 bytes reach nfnatsetupinfo() uninitialised.

KMSAN reports an uninit-value in nfnatsetupinfo() reached from nftnateval(). The IPv6 path fills all 16 bytes and is not affected.

Zero-initialise newaddr.

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

netfilter: flowtable: hold reference on ct until flow is released

nfctput() releases the ct->ext area inmediately, the rcu typesafe semantics also allow to refer to the wrong conntrack from the flowtable datapath. Hold reference on ct until flow is released after rcu grace period.

Add rcubarrier() on module exit path, to ensure pending flow entries are release before module goes away.