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

blktrace: fix thiscpuread/write in preemptible context

tracingrecordcmdline() internally uses thiscpuread() and thiscpuwrite() on the per-CPU variable tracecmdlinesave, and tracesavecmdline() explicitly asserts preemption is disabled via lockdepassertpreemptiondisabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probewakeupschedswitch() / probewakeup()).

blkaddtrace() was calling tracingrecordcmdline(current) early in the blktracer path, before ring buffer reservation, from process context where preemption is fully enabled. This triggers the following using blktests/blktrace/002:

blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] nullblk: disk nullb1 created [ 81.357294] BUG: using thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)

[ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] nullblk: disk nullb1 created [ 81.357294] BUG: using thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 [ 81.362895] checkpreemptiondisabled+0xce/0xe0 [ 81.362902] tracingrecordcmdline+0x10/0x40 [ 81.362923] blkaddtrace+0x307/0x5d0 [ 81.362934] ? lockacquire+0xe0/0x300 [ 81.362940] ? ioviterextractpages+0x101/0xa30 [ 81.362959] blkaddtracebio+0x106/0x1e0 [ 81.362968] submitbionoacctnocheck+0x24b/0x3a0 [ 81.362979] ? lockdepinitmaptype+0x58/0x260 [ 81.362988] submitbiowait+0x56/0x90 [ 81.363009] blkdevdirectIOsimple+0x16c/0x250 [ 81.363026] ? pfxsubmitbiowaitendio+0x10/0x10 [ 81.363038] ? rcureadlockanyheld+0x73/0xa0 [ 81.363051] blkdevreaditer+0xc1/0x140 [ 81.363059] vfsread+0x20b/0x330 [ 81.363083] ksysread+0x67/0xe0 [ 81.363090] dosyscall64+0xbf/0xf00 [ 81.363102] entrySYSCALL64afterhwframe+0x76/0x7e [ 81.363106] RIP: 0033:0x7f281906029d [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000 [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000 [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000 [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a [ 81.363142] </TASK>

The same BUG fires from blkaddtraceplug(), blkaddtraceunplug(), and blkaddtracerq() paths as well.

The purpose of tracin ---truncated---

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

accel/amdxdna: Fix NULL pointer dereference of mgmtchann

mgmtchann may be set to NULL if the firmware returns an unexpected error in aie2sendmgmtmsgwait(). This can later lead to a NULL pointer dereference in aie2hwstop().

Fix this by introducing a dedicated helper to destroy mgmtchann and by adding proper NULL checks before accessing it.

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

openvswitch: vport: fix self-deadlock on release of tunnel ports

vports are used concurrently and protected by RCU, so netdevput() must happen after the RCU grace period. So, either in an RCU call or after the synchronizenet(). The rtnldeletelink() must happen under RTNL and so can't be executed in RCU context. Calling synchronizenet() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdevput() in RCU call is the right solution here.

However, when the device is deleted, rtnlunlock() will call netdevruntodo() and block until all the references are gone. In the current code this means that we never reach the callrcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal.

Fix that by moving the rcucall() before the rtnlunlock(), so the scheduled RCU callback will be executed when synchronizenet() is called from the rtnlunlock()->netdevruntodo() while the RTNL itself is already released.

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

ixgbevf: add missing negotiatefeatures op to Hyper-V ops table

Commit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features") added the .negotiatefeatures callback to ixgbemacoperations and populated it in ixgbevfmacops, but forgot to add it to ixgbevfhvmacops. This leaves the function pointer NULL on Hyper-V VMs.

During probe, ixgbevfnegotiateapi() calls ixgbevfsetfeatures(), which unconditionally dereferences hw->mac.ops.negotiatefeatures(). On Hyper-V this results in a NULL pointer dereference:

BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...] Workqueue: events workforcpufn RIP: 0010:0x0 [...] Call Trace: ixgbevfnegotiateapi+0x66/0x160 [ixgbevf] ixgbevfswinit+0xe4/0x1f0 [ixgbevf] ixgbevfprobe+0x20f/0x4a0 [ixgbevf] localpciprobe+0x50/0xa0 workforcpufn+0x1a/0x30 [...]

Add ixgbevfhvnegotiatefeaturesvf() that returns -EOPNOTSUPP and wire it into ixgbevfhvmacops. The caller already handles -EOPNOTSUPP gracefully.

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

xfrmuser: fix info leak in buildmapping()

struct xfrmusersaid has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.

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

netfilter: nfnetlinklog: initialize nfgenmsg in NLMSGDONE terminator

When batching multiple NFLOG messages (inst->qlen > 1), nfulnlsend() appends an NLMSGDONE terminator with sizeof(struct nfgenmsg) payload via nlmsgput(), but never initializes the nfgenmsg bytes. The nlmsgput() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSGDONE message body.

Use nfnlmsgput() to build the NLMSGDONE terminator, which initializes the nfgenmsg payload via nfnlfillhdr(), consistent with how buildpacketmessage() already constructs NFULNLMSGPACKET headers.

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

l2tp: Drop large packets with UDP encap

syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code.

syzbot's repro:

r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1)

It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tpxmitcore doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites.

Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire.

syzbot's stack trace (with my patch applied):

len >= 65536u WARNING: ./include/linux/udp.h:38 at udpsetlenshort include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tpxmitcore net/l2tp/l2tpcore.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tpxmitskb+0x1204/0x18d0 net/l2tp/l2tpcore.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udpsetlenshort include/linux/udp.h:38 [inline] RIP: 0010:l2tpxmitcore net/l2tp/l2tpcore.c:1293 [inline] RIP: 0010:l2tpxmitskb+0x1204/0x18d0 net/l2tp/l2tpcore.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: <TASK> pppol2tpsendmsg+0x40a/0x5f0 net/l2tp/l2tpppp.c:302 socksendmsgnosec net/socket.c:727 [inline] socksendmsg net/socket.c:742 [inline] sockwriteiter+0x503/0x550 net/socket.c:1195 doiterreadvwritev+0x619/0x8c0 fs/readwrite.c:-1 vfswritev+0x33c/0x990 fs/readwrite.c:1059 dowritev+0x154/0x2e0 fs/readwrite.c:1105 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x14d/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIGRAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 </TASK>

[1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/

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

netfilter: xtmultiport: validate range encoding in checkentry

portsmatchv1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.

The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving portsmatchv1() to step past the last valid ports[] element while interpreting the rule.

Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.

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

xfrmuser: fix info leak in buildreport()

struct xfrmuserreport is a u8 proto field followed by a struct xfrmselector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.

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

net: rfkill: prevent unlimited numbers of rfkill events from being created

Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a "large" number (i.e. 1000) to prevent abuses like this.

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

xfrm: clear trailing padding in buildpolexpire()

buildexpire() clears the trailing padding bytes of struct xfrmuserexpire after setting the hard field via memsetafter(), but the analogous function buildpolexpire() does not do this for struct xfrmuserpolexpire.

The padding bytes after the u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRPEXPIRE listeners, leaking kernel heap memory contents.

Add the missing memsetafter() call, matching buildexpire().

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

mmc: vub300: fix NULL-deref on disconnect

Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.

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

rxrpc: Fix call removal to use RCU safe deletion

Fix rxrpc call removal from the rxnet->calls list to use listdelrcu() rather than listdelinit() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop.

This, however, means that listempty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by:

Firstly, make rxrpcdestroyallcalls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call condresched() or to remove calls from the list here, thereby eliminating the need for rxrpcputcall() to check for that.

rxrpcputcall() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.

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

rxrpc: fix reference count leak in rxrpcserverkeyring()

This patch fixes a reference count leak in rxrpcserverkeyring() by checking if rx->securities is already set.

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

RDMA/irdma: Fix deadlock during netdev reset with active connections

Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering devicedelete and subsequent client removal. During client removal, uverbsclient waits for QP reference count to reach zero while cmaclient holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.

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

net: bonding: fix NULL deref in bonddebugrlbhashshow

rlbclearslave intentionally keeps RLB hash-table entries on the rxhashtblusedhead list with slave set to NULL when no replacement slave is available. However, bonddebugrlbhashshow visites clientinfo->slave without checking if it's NULL.

Other used-list iterators in bondalb.c already handle this NULL-slave state safely:

- rlbupdateclient returns early on !clientinfo->slave - rlbrequpdateslaveclients, rlbclearslave, and rlbrebalance compare slave values before visiting - lbrequpdatesubnetclients continues if slave is NULL

The following NULL deref crash can be trigger in bonddebugrlbhashshow:

[ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.292058] RIP: 0010:bonddebugrlbhashshow (drivers/net/bonding/bonddebugfs.c:41) [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286 [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204 [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078 [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000 [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0 [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8 [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000 [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0 [ 1.295897] Call Trace: [ 1.296134] seqreaditer (fs/seqfile.c:231) [ 1.296341] seqread (fs/seqfile.c:164) [ 1.296493] fullproxyread (fs/debugfs/file.c:378 (discriminator 1)) [ 1.296658] vfsread (fs/readwrite.c:572) [ 1.296981] ksysread (fs/readwrite.c:717) [ 1.297132] dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) [ 1.297325] entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Add a NULL check and print "(none)" for entries with no assigned slave.

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

udp: Fix wildcard bind conflict check when using hash2

When binding a udpsock to a local address and port, UDP uses two hashes (udptable->hash and udptable->hash2) for collision detection. The current code switches to "hash2" when hslot->count > 10.

"hash2" is keyed by local address and local port. "hash" is keyed by local port only.

The issue can be shown in the following bind sequence (pseudo code):

bind(fd1, "[fd00::1]:8888") bind(fd2, "[fd00::2]:8888") bind(fd3, "[fd00::3]:8888") bind(fd4, "[fd00::4]:8888") bind(fd5, "[fd00::5]:8888") bind(fd6, "[fd00::6]:8888") bind(fd7, "[fd00::7]:8888") bind(fd8, "[fd00::8]:8888") bind(fd9, "[fd00::9]:8888") bind(fd10, "[fd00::10]:8888")

/ Correctly return -EADDRINUSE because "hash" is used instead of "hash2". udpliblportinuse() detects the conflict. / bind(failfd, "[::]:8888")

/ After one more socket is bound to "[fd00::11]:8888", hslot->count exceeds 10 and "hash2" is used instead. / bind(fd11, "[fd00::11]:8888") bind(failfd, "[::]:8888") / succeeds unexpectedly /

The same issue applies to the IPv4 wildcard address "0.0.0.0" and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For example, if there are existing sockets bound to "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or "[::ffff:0.0.0.0]:8888" can also miss the conflict when hslot->count > 10.

TCP inetcskgetport() already has the correct check in inetusebhash2onbind(). Rename it to inetusehash2onbind() and move it to inethashtables.h so udp.c can reuse it in this fix.

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

netfilter: nfconntrackexpect: skip expectations in other netns via proc

Skip expectations that do not reside in this netns.

Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns's conntrack entries via proc").

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

netfilter: ctnetlink: use netlink policy range checks

Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors.

- CTAPROTOINFOTCPSTATE: reject values > TCPCONNTRACKSYNSENT2 at policy level, removing the manual >= TCPCONNTRACKMAX check. - CTAPROTOINFOTCPWSCALEORIGINAL/REPLY: reject values > TCPMAXWSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTAFILTERORIGFLAGS/REPLYFLAGS: use NLAPOLICYMASK with CTAFILTERFALL, removing the manual mask checks. - CTAEXPECTFLAGS: use NLAPOLICYMASK with NFCTEXPECTMASK, adding a new mask define grouping all valid expect flags.

Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.

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

ipv6: avoid overflows in ip6datagramsendctl()

Yiming Qian reported : <quote> I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via skbunderpanic() (local DoS).

The core issue is a mismatch between:

- a 16-bit length accumulator (struct ipv6txoptions::optflen, type u16) and - a pointer to the last provided destination-options header (opt->dst1opt)

when multiple IPV6DSTOPTS control messages (cmsgs) are provided.

- include/net/ipv6.h: - struct ipv6txoptions::optflen is u16 (wrap possible). (lines 291-307, especially 298) - net/ipv6/datagram.c:ip6datagramsendctl(): - Accepts repeated IPV6DSTOPTS and accumulates into optflen without rejecting duplicates. (lines 909-933) - net/ipv6/ip6output.c:ip6appenddata(): - Uses opt->optflen + opt->optnflen to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - net/ipv6/ip6output.c:ip6makeskb(): - Calls ipv6pushfragopts() if opt->optflen is non-zero. (lines 1930-1934) - net/ipv6/exthdrs.c:ipv6pushfragopts() / ipv6pushexthdr(): - Push size comes from ipv6optlen(opt->dst1opt) (based on the pointed-to header). (lines 1179-1185 and 1206-1211)

1. optflen is a 16-bit accumulator:

- include/net/ipv6.h:298 defines u16 optflen; / after fragment hdr /.

2. ip6datagramsendctl() accepts repeated IPV6DSTOPTS cmsgs and increments optflen each time:

- In net/ipv6/datagram.c:909-933, for IPV6DSTOPTS: - It computes len = ((hdr->hdrlen + 1) << 3); - It checks CAPNETRAW using nscapable(net->userns, CAPNETRAW). (line 922) - Then it does: - opt->optflen += len; (line 927) - opt->dst1opt = hdr; (line 928)

There is no duplicate rejection here (unlike the legacy IPV62292DSTOPTS path which rejects duplicates at net/ipv6/datagram.c:901-904).

If enough large IPV6DSTOPTS cmsgs are provided, optflen wraps while dst1opt still points to a large (2048-byte) destination-options header.

In the attached PoC (poc.c):

- 32 cmsgs with hdrlen=255 => len = (255+1)8 = 2048 - 1 cmsg with hdrlen=0 => len = 8 - Total increment: 322048 + 8 = 65544, so (u16)optflen == 8 - The last cmsg is 2048 bytes, so dst1opt points to a 2048-byte header.

3. The transmit path sizes headers using the wrapped optflen:

- In net/ipv6/ip6output.c:1463-1465: - headersize = sizeof(struct ipv6hdr) + (opt ? opt->optflen + opt->optnflen : 0) + ...;

With wrapped optflen, headersize/headroom decisions underestimate what will be pushed later.

4. When building the final skb, the actual push length comes from dst1opt and is not limited by wrapped optflen:

- In net/ipv6/ip6output.c:1930-1934: - if (opt->optflen) proto = ipv6pushfragopts(skb, opt, proto); - In net/ipv6/exthdrs.c:1206-1211, ipv6pushfragopts() pushes dst1opt via ipv6pushexthdr(). - In net/ipv6/exthdrs.c:1179-1184, ipv6pushexthdr() does: - skbpush(skb, ipv6optlen(opt)); - memcpy(h, opt, ipv6optlen(opt));

With insufficient headroom, skbpush() underflows and triggers skbunderpanic() -> BUG():

- net/core/skbuff.c:2669-2675 (skbpush() calls skbunderpanic()) - net/core/skbuff.c:207-214 (skbpanic() ends in BUG())

- The IPV6DSTOPTS cmsg path requires CAPNETRAW in the target netns user namespace (nscapable(net->userns, CAPNETRAW)). - Root (or any task with CAPNETRAW) can trigger this without user namespaces. - An unprivileged uid=1000 user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced CAPNETRAW (the attached PoC does this).

- Local denial of service: kernel BUG/panic (system crash). - ---truncated---

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

net: atm: fix crash due to unvalidated vcc pointer in sigdsend()

Reproducer available at [1].

The ATM send path (sendmsg -> vccsendmsg -> sigdsend) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AFATMSVC, SOCKDGRAM, 0); ioctl(fd, ATMSIGDCTRL); // become ATM signaling daemon struct msghdr msg = { .msgiov = &iov, ... }; (unsigned long )(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigdenq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing findgetvcc() which validates the pointer by searching through vcchash (similar to how sigdclose() iterates over all VCCs), and acquires a reference via sockhold() if found.

Since struct atmvcc embeds struct sock as its first member, they share the same lifetime. Therefore using sockhold/sockput is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigdclose() which could mark the vcc with various flags (e.g., ATMVFRELEASED) after findgetvcc() returns. However, sockhold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

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

net: usb: aqc111: Do not perform PM inside suspend callback

syzbot reports "task hung in rpmresume"

This is caused by aqc111suspend calling the PM variant of its writecmd routine.

The simplified call trace looks like this:

rpmsuspend() usbsuspendboth() - here udev->dev.power.runtimestatus == RPMSUSPENDING aqc111suspend() - called for the usb device interface aqc111write32cmd() usbautopmgetinterface() pmruntimeresumeandget() rpmresume() - here we call rpmresume() on our parent rpmresume() - Here we wait for a status change that will never happen.

At this point we block another task which holds rtnllock and locks up the whole networking stack.

Fix this by replacing the writecmd calls with their nopm variants

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

ipv6: add NULL checks for idev in SRv6 paths

in6devget() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6MINMTU or after NETDEVUNREGISTER).

Add NULL checks for idev returned by in6devget() in both seg6hmacvalidateskb() and ipv6srhrcv() to prevent potential NULL pointer dereferences.

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

udptunnel: fix NULL deref caused by udpsockcreate6 when CONFIGIPV6=n

When CONFIGIPV6 is disabled, the udpsockcreate6() function returns 0 (success) without actually creating a socket. Callers such as foucreate() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference.

The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:founladddoit (net/ipv4/foucore.c:590 net/ipv4/foucore.c:764) [...] Call Trace: <TASK> genlfamilyrcvmsgdoit.constprop.0 (net/netlink/genetlink.c:1114) genlrcvmsg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlinkrcvskb (net/netlink/afnetlink.c:2550) genlrcv (net/netlink/genetlink.c:1219) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) socksendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) syssendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) x64syssendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) entrySYSCALL64afterhwframe (net/arch/x86/entry/entry64.S:130)

This patch makes udpsockcreate6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.

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

net: mvpp2: guard flow control update with globaltxfc in buffer switching

mvpp2bmswitchbuffers() unconditionally calls mvpp2bmpoolupdateprivfc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2cm3read()/mvpp2cm3write(), which dereference priv->cm3base without any NULL check.

When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c ("dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree")), priv->cm3base remains NULL and priv->globaltxfc is false. Any operation that triggers mvpp2bmswitchbuffers(), for example an MTU change that crosses the jumbo frame threshold, will crash:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2cm3read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2bmpoolupdatefc+0x40/0x12c mvpp2bmpoolupdateprivfc+0x94/0xd8 mvpp2bmswitchbuffers.isra.0+0x80/0x1c0 mvpp2changemtu+0x140/0x380 devsetmtu+0x1c/0x38 devsetmtuext+0x78/0x118 devsetmtu+0x48/0xa8 devifsioc+0x21c/0x43c devioctl+0x2d8/0x42c sockioctl+0x314/0x378

Every other flow control call site in the driver already guards hardware access with either priv->globaltxfc or port->txfc. mvpp2bmswitchbuffers() is the only place that omits this check.

Add the missing priv->globaltxfc guard to both the disable and re-enable calls in mvpp2bmswitchbuffers(), consistent with the rest of the driver.

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

nftables: nftdynset: fix possible stateful expression memleak in error path

If cloning the second stateful expression in the element via GFPATOMIC fails, then the first stateful expression remains in place without being released.

unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm "softirq", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpuallocnoprof+0x453/0xd80       nftcounterclone+0x9c/0x190 [nftables]       nftexprclone+0x8f/0x1b0 [nftables]       nftdynsetnew+0x2cb/0x5f0 [nftables]       nftrhashupdate+0x236/0x11c0 [nftables]       nftdynseteval+0x11f/0x670 [nftables]       nftdochain+0x253/0x1700 [nftables]       nftdochainipv4+0x18d/0x270 [nftables]       nfhookslow+0xaa/0x1e0       iplocaldeliver+0x209/0x330

icmp: fix NULL pointer dereference in icmptagvalidation()

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

wifi: mac80211: fix NULL deref in meshmatcheslocal()

meshmatcheslocal() unconditionally dereferences ie->meshconfig to compare mesh configuration parameters. When called from meshrxcsaframe(), the parsed action-frame elements may not contain a Mesh Configuration IE, leaving ie->meshconfig NULL and triggering a kernel NULL pointer dereference.

The other two callers are already safe: - ieee80211meshrxbcnpresp() checks !elems->meshconfig before calling meshmatcheslocal() - meshplinkgetevent() is only reached through meshprocessplinkframe(), which checks !elems->meshconfig, too

meshrxcsaframe() is the only caller that passes raw parsed elements to meshmatcheslocal() without guarding meshconfig. An adjacent attacker can exploit this by sending a crafted CSA action frame that includes a valid Mesh ID IE but omits the Mesh Configuration IE, crashing the kernel.

The captured crash log:

Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: eventsunbound cfg80211wiphywork [...] Call Trace: <TASK> ? pfxmeshmatcheslocal (net/mac80211/mesh.c:65) ieee80211meshrxqueuedmgmt (net/mac80211/mesh.c:1686) [...] ieee80211ifacework (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211wiphywork (net/wireless/core.c:426) processonework (net/kernel/workqueue.c:3280) ? assignwork (net/kernel/workqueue.c:1219) workerthread (net/kernel/workqueue.c:3352) ? pfxworkerthread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] retfromforkasm (net/arch/x86/entry/entry64.S:255) </TASK>

This patch adds a NULL check for ie->meshconfig at the top of meshmatcheslocal() to return false early when the Mesh Configuration IE is absent.

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

ice: Fix memory leak in icesetringparam()

In icesetringparam, txrings and xdprings are allocated before rxrings. If the allocation of rxrings fails, the code jumps to the done label leaking both txrings and xdprings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the freetx label which releases txrings but leaks xdprings.

Fix this by introducing a freexdp label and updating the error paths to ensure both xdprings and txrings are properly freed if rxrings allocation or setup fails.

Compile tested only. Issue found using a prototype static analysis tool and code review.

HID: Add HIDCLAIMEDINPUT guards in rawevent callbacks missing them