The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bpf: consider that tail calls invalidate packet pointers

Tail-called programs could execute any of the helpers that invalidate packet pointers. Hence, conservatively assume that each tail call invalidates packet pointers.

Making the change in bpfhelperchangespktdata() automatically makes use of checkcfg() logic that computes 'changespkt_data' effect for global sub-programs, such that the following program could be rejected:

int tail_call(struct __sk_buff *sk)
{
    bpf_tail_call_static(sk, &jmp_table, 0);
    return 0;
}

SEC("tc")
int not_safe(struct __sk_buff *sk)
{
    int *p = (void *)(long)sk->data;
    ... make p valid ...
    tail_call(sk);
    *p = 42; /* this is unsafe */
    ...
}

The tcbpf2bpf.c:subprogtc() needs change: mark it as a function that can invalidate packet pointers. Otherwise, it can't be freplaced with tailcallfreplace.c:entryfreplace() that does a tail call.(CVE-2024-58237)

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

netem: Update sch->q.qlen before qdisctreereduce_backlog()

qdisctreereducebacklog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlennotify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list.(CVE-2025-21703)

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

RDMA/rxe: Fix the warning "_rxecleanup+0x12c/0x170 [rdma_rxe]"

The Call Trace is as below: " <TASK> ? showregs.cold+0x1a/0x1f ? _rxecleanup+0x12c/0x170 [rdmarxe] ? _warn+0x84/0xd0 ? _rxecleanup+0x12c/0x170 [rdmarxe] ? reportbug+0x105/0x180 ? handlebug+0x46/0x80 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? _rxecleanup+0x12c/0x170 [rdmarxe] ? _rxecleanup+0x124/0x170 [rdmarxe] rxedestroyqp.cold+0x24/0x29 [rdmarxe] ibdestroyqpuser+0x118/0x190 [ibcore] rdmadestroyqp.cold+0x43/0x5e [rdmacm] rtrscqqpdestroy.cold+0x1d/0x2b [rtrscore] rtrssrvclosework.cold+0x1b/0x31 [rtrsserver] processonework+0x21d/0x3f0 workerthread+0x4a/0x3c0 ? processonework+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthreadcompleteandexit+0x20/0x20 retfrom_fork+0x22/0x30 </TASK> " When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly.

Compared with other rdma drivers, a bigger timeout is used.(CVE-2025-21829)

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

net: enetc: VFs do not support HWTSTAMPTXONESTEP_SYNC

Actually ENETC VFs do not support HWTSTAMPTXONESTEPSYNC because only ENETC PF can access PMaSINGLE_STEP registers. And there will be a crash if VFs are used to test one-step timestamp, the crash log as follows.

[ 129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0 [ 129.287769] Call trace: [ 129.290219] enetcportmacwr+0x30/0xec (P) [ 129.294504] enetcstartxmit+0xda4/0xe74 [ 129.298525] enetcxmit+0x70/0xec [ 129.301848] devhardstart_xmit+0x98/0x118(CVE-2025-21894)

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

caifvirtio: fix wrong pointer check in cfvprobe()

delvqs() frees virtqueues, therefore cfv->vqtx pointer should be checked for NULL before calling it, not cfv->vdev. Also the current implementation is redundant because the pointer cfv->vdev is dereferenced before it is checked for NULL.

Fix this by checking cfv->vqtx for NULL instead of cfv->vdev before calling delvqs().(CVE-2025-21904)

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

vlan: enforce underlying device type

Currently, VLAN devices can be created on top of non-ethernet devices.

Besides the fact that it doesn't make much sense, this also causes a bug which leaks the address of a kernel function to usermode.

When creating a VLAN device, we initialize GARP (garpinitapplicant) and MRP (mrpinitapplicant) for the underlying device.

As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling devmcadd.

_devmcadd uses dev->addrlen to determine the length of the new multicast address.

This causes an out-of-bounds read if dev->addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long.

This behaviour can be reproduced using the following commands:

ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100

Then, the following command will display the address of garppdurcv:

ip maddr show | grep 01:80:c2:00:00:21

Fix the bug by enforcing the type of the underlying device during VLAN device initialization.(CVE-2025-21920)

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

net: gso: fix ownership in _udpgso_segment

In _udpgso_segment the skb destructor is removed before segmenting the skb but the socket reference is kept as-is. This is an issue if the original skb is later orphaned as we can hit the following bug:

kernel BUG at ./include/linux/skbuff.h:3312! (skborphan) RIP: 0010:iprcvcore+0x8b2/0xca0 Call Trace: iprcv+0xab/0x6e0 _netifreceiveskbonecore+0x168/0x1b0 processbacklog+0x384/0x1100 _napipoll.constprop.0+0xa1/0x370 netrxaction+0x925/0xe50

The above can happen following a sequence of events when using OpenVSwitch, when an OVSACTIONATTRUSERSPACE action precedes an OVSACTIONATTROUTPUT action:

1. OVSACTIONATTRUSERSPACE is handled (in doexecuteactions): the skb goes through queuegsopackets and then _udpgsosegment, where its destructor is removed.
2. The segments' data are copied and sent to userspace.
3. OVSACTIONATTROUTPUT is handled (in doexecute_actions) and the same original skb is sent to its path.
4. If it later hits skb_orphan, we hit the bug.

Fix this by also removing the reference to the socket in _udpgso_segment.(CVE-2025-21926)

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

mptcp: fix 'scheduling while atomic' in mptcppmnlappendnewlocaladdr

If multiple connection requests attempt to create an implicit mptcp endpoint in parallel, more than one caller may end up in mptcppmnlappendnewlocaladdr because none found the address in localaddrlist during their call to mptcppmnlgetlocalid. In this case, the concurrent newlocaladdr calls may delete the address entry created by the previous caller. These deletes use synchronizercu, but this is not permitted in some of the contexts where this function may be called. During packet recv, the caller may be in a rcu read critical section and have preemption disabled.

An example stack:

BUG: scheduling while atomic: swapper/2/0/0x00000302

Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:117 (discriminator 1)) dumpstack (lib/dumpstack.c:124) _schedulebug (kernel/sched/core.c:5943) scheduledebug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970) _schedule (arch/x86/include/asm/jumplabel.h:27 include/linux/jumplabel.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818) scheduletimeout (kernel/time/timer.c:2160) waitforcompletion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148) _waitrcugp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444) synchronizercu (kernel/rcu/tree.c:3609) mptcppmnlappendnewlocaladdr (net/mptcp/pmnetlink.c:966 net/mptcp/pmnetlink.c:1061) mptcppmnlgetlocalid (net/mptcp/pmnetlink.c:1164) mptcppmgetlocalid (net/mptcp/pm.c:420) subflowcheckreq (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflowv4routereq (net/mptcp/subflow.c:305) tcpconnrequest (net/ipv4/tcpinput.c:7216) subflowv4connrequest (net/mptcp/subflow.c:651) tcprcvstateprocess (net/ipv4/tcpinput.c:6709) tcpv4dorcv (net/ipv4/tcpipv4.c:1934) tcpv4rcv (net/ipv4/tcpipv4.c:2334) ipprotocoldeliverrcu (net/ipv4/ipinput.c:205 (discriminator 1)) iplocaldeliverfinish (include/linux/rcupdate.h:813 net/ipv4/ipinput.c:234) iplocaldeliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ipinput.c:254) ipsublistrcvfinish (include/net/dst.h:461 net/ipv4/ipinput.c:580) ipsublistrcv (net/ipv4/ipinput.c:640) iplistrcv (net/ipv4/ipinput.c:675) _netifreceiveskblistcore (net/core/dev.c:5583 net/core/dev.c:5631) netifreceiveskblistinternal (net/core/dev.c:5685 net/core/dev.c:5774) napicompletedone (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114) igbpoll (drivers/net/ethernet/intel/igb/igbmain.c:8244) igb _napipoll (net/core/dev.c:6582) netrxaction (net/core/dev.c:6653 net/core/dev.c:6787) handlesoftirqs (kernel/softirq.c:553) _irqexitrcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636) irqexitrcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ>

This problem seems particularly prevalent if the user advertises an endpoint that has a different external vs internal address. In the case where the external address is advertised and multiple connections already exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the first localaddrlist entries which have the internal address instead.

Fix by skipping the replacement of an existing implicit local address if called via mptcppmnlgetlocal_id.(CVE-2025-21938)

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

eth: bnxt: do not update checksum in bnxtxdpbuild_skb()

The bnxtrxpkt() updates ipsummed value at the end if checksum offload is enabled. When the XDP-MB program is attached and it returns XDPPASS, the bnxtxdpbuildskb() is called to update skbsharedinfo. The main purpose of bnxtxdpbuildskb() is to update skbsharedinfo, but it updates ip_summed value too if checksum offload is enabled. This is actually duplicate work.

When the bnxtrxpkt() updates ipsummed value, it checks if ipsummed is CHECKSUMNONE or not. It means that ipsummed should be CHECKSUMNONE at this moment. But ipsummed may already be updated to CHECKSUMUNNECESSARY in the XDP-MB-PASS path. So the by skbchecksumnoneassert() WARNS about it.

This is duplicate work and updating ipsummed in the bnxtxdpbuildskb() is not needed.

Splat looks like: WARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxtrxpkt+0x479b/0x7610 [bnxten] Modules linked in: bnxtre bnxten rdmaucm rdmacm iwcm ibcm ibuverbs veth xtnat xttcpudp xtconntrack nftchainnat xtMASQUERADE nf] CPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G W 6.14.0-rc4+ #27 Tainted: [W]=WARN Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bnxtrxpkt+0x479b/0x7610 [bnxten] Code: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b f RSP: 0018:ffff88881ba09928 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000 RDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8 RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070 R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080 R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000 FS: 00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <IRQ> ? warn+0xcd/0x2f0 ? bnxtrxpkt+0x479b/0x7610 ? reportbug+0x326/0x3c0 ? handlebug+0x53/0xa0 ? excinvalidop+0x14/0x50 ? asmexcinvalidop+0x16/0x20 ? bnxtrxpkt+0x479b/0x7610 ? bnxtrxpkt+0x3e41/0x7610 ? _pfxbnxtrxpkt+0x10/0x10 ? napicompletedone+0x2cf/0x7d0 _bnxtpollwork+0x4e8/0x1220 ? _pfxbnxtpollwork+0x10/0x10 ? _pfxmarklock.part.0+0x10/0x10 bnxtpollp5+0x36a/0xfa0 ? _pfxbnxtpollp5+0x10/0x10 _napipoll.constprop.0+0xa0/0x440 netrx_action+0x899/0xd00 ...

Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be able to reproduce this issue.(CVE-2025-21960)

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

eth: bnxt: fix truesize for mb-xdp-pass case

When mb-xdp is set and return is XDPPASS, packet is converted from xdpbuff to skbuff with xdpupdateskbsharedinfo() in bnxtxdpbuildskb(). bnxtxdpbuildskb() passes incorrect truesize argument to xdpupdateskbsharedinfo(). The truesize is calculated as BNXTRXPAGESIZE * sinfo->nrfrags but the skbsharedinfo was wiped by napibuildskb() before. So it stores sinfo->nrfrags before bnxtxdpbuildskb() and use it instead of getting skbsharedinfo from xdpgetsharedinfofrombuff().

Splat looks like: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skbtrycoalesce+0x504/0x590 Modules linked in: xtnat xttcpudp veth afpacket xtconntrack nftchainnat xtMASQUERADE nfconntracknetlink xfrmuser xtaddrtype nftcoms CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3 RIP: 0010:skbtrycoalesce+0x504/0x590 Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99 RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287 RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0 RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003 RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900 R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740 R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <IRQ> ? _warn+0x84/0x130 ? skbtrycoalesce+0x504/0x590 ? reportbug+0x18a/0x1a0 ? handlebug+0x53/0x90 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? skbtrycoalesce+0x504/0x590 inetfragreasmfinish+0x11f/0x2e0 ipdefrag+0x37a/0x900 iplocaldeliver+0x51/0x120 ipsublistrcvfinish+0x64/0x70 ipsublistrcv+0x179/0x210 iplist_rcv+0xf9/0x130

How to reproduce: <Node A> ip link set $interface1 xdp obj xdp_pass.o ip link set $interface1 mtu 9000 up ip a a 10.0.0.1/24 dev $interface1 <Node B> ip link set $interfac2 mtu 9000 up ip a a 10.0.0.2/24 dev $interface2 ping 10.0.0.1 -s 65000

Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be able to reproduce this issue.(CVE-2025-21961)

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

net/mlx5: handle errors in mlx5chainscreate_table()

In mlx5chainscreatetable(), the return value of mlx5getfdbsubns() and mlx5getflownamespace() must be checked to prevent NULL pointer dereferences. If either function fails, the function should log error message with mlx5corewarn() and return error pointer.(CVE-2025-21975)

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

xsk: fix an integer overflow in xpcreateandassignumem()

Since the i and pool->chunk_size variables are of type 'u32', their product can wrap around and then be cast to 'u64'. This can lead to two different XDP buffers pointing to the same memory area.

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21997)

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

net: atm: fix use after free in lec_send()

The ->send() operation frees skb so save the length before calling ->send() to avoid a use after free.(CVE-2025-22004)

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

usbnet:fix NPE during rx_complete

Missing usbnetgoingaway Check in Critical Path. The usbsubmiturb function lacks a usbnetgoingaway validation, whereas _usbnetqueue_skb includes this check.

This inconsistency creates a race condition where: A URB request may succeed, but the corresponding SKB data fails to be queued.

Subsequent processes: (e.g., rxcomplete → deferbh → _skbunlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).(CVE-2025-22050)

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

net: ibmveth: make vethpoolstore stop hanging

v2: - Created a single error handling unlock and exit in vethpoolstore - Greatly expanded commit message with previous explanatory-only text

Summary: Use rtnlmutex to synchronize vethpoolstore with itself, ibmvethclose and ibmvethopen, preventing multiple calls in a row to napidisable.

Background: Two (or more) threads could call vethpoolstore through writing to /sys/devices/vio/30000002/pool/. You can do this easily with a little shell script. This causes a hang.

I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw:

Setting pool0/active to 0
Setting pool1/active to 1
[   73.911067][ T4365] ibmveth 30000002 eth0: close starting
Setting pool1/active to 1
Setting pool1/active to 0
[   73.911367][ T4366] ibmveth 30000002 eth0: close starting
[   73.916056][ T4365] ibmveth 30000002 eth0: close complete
[   73.916064][ T4365] ibmveth 30000002 eth0: open starting
[  110.808564][  T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
[  230.808495][  T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
[  243.683786][  T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.
[  243.683827][  T123]       Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8
[  243.683833][  T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  243.683838][  T123] task:stress.sh       state:D stack:28096 pid:4365  tgid:4365  ppid:4364   task_flags:0x400040 flags:0x00042000
[  243.683852][  T123] Call Trace:
[  243.683857][  T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)
[  243.683868][  T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0
[  243.683878][  T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0
[  243.683888][  T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210
[  243.683896][  T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50
[  243.683904][  T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0
[  243.683913][  T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60
[  243.683921][  T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc
[  243.683928][  T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270
[  243.683936][  T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0
[  243.683944][  T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0
[  243.683951][  T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650
[  243.683958][  T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150
[  243.683966][  T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340
[  243.683973][  T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec
...
[  243.684087][  T123] Showing all locks held in the system:
[  243.684095][  T123] 1 lock held by khungtaskd/123:
[  243.684099][  T123]  #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248
[  243.684114][  T123] 4 locks held by stress.sh/4365:
[  243.684119][  T123]  #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
[  243.684132][  T123]  #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0
[  243.684143][  T123]  #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0
[  243.684155][  T123]  #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60
[  243.684166][  T123] 5 locks held by stress.sh/4366:
[  243.684170][  T123]  #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
[  243.

---truncated---(CVE-2025-22053)

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

arcnet: Add NULL check in com20020pci_probe()

devmkasprintf() returns NULL when memory allocation fails. Currently, com20020pciprobe() does not check for this case, which results in a NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue and ensure no resources are left allocated.(CVE-2025-22054)

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

net: fix geneve_opt length integer overflow

struct geneve_opt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes.

However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to fake a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read.

One example crash log is like below:

[ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nlaput+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] <TASK> [ 3.908048] dumpstacklvl+0x44/0x5c [ 3.908258] printreport+0x184/0x4be [ 3.909151] kasanreport+0xc5/0x100 [ 3.909539] kasancheckrange+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nlaput+0xa9/0xe0 [ 3.910147] tunnelkeydump+0x945/0xba0 [ 3.911536] tcfactiondump1+0x1c1/0x340 [ 3.912436] tcfactiondump+0x101/0x180 [ 3.912689] tcfextsdump+0x164/0x1e0 [ 3.912905] fwdump+0x18b/0x2d0 [ 3.913483] tcffillnode+0x2ee/0x460 [ 3.914778] tfilternotify+0xf4/0x180 [ 3.915208] tcnewtfilter+0xd51/0x10d0 [ 3.918615] rtnetlinkrcvmsg+0x4a2/0x560 [ 3.919118] netlinkrcvskb+0xcd/0x200 [ 3.919787] netlinkunicast+0x395/0x530 [ 3.921032] netlinksendmsg+0x3d0/0x6d0 [ 3.921987] _socksendmsg+0x99/0xa0 [ 3.922220] _syssendto+0x1b7/0x240 [ 3.922682] _x64syssendto+0x72/0x90 [ 3.922906] dosyscall64+0x5e/0x90 [ 3.923814] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8

Fix these issues by enforing correct length condition in related policies.(CVE-2025-22055)

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

udp: Fix memory accounting leak.

Matt Dowling reported a weird UDP memory usage issue.

Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops.

We can reproduce the issue with the script below [0]:

1. /proc/net/sockstat reports 0 pages

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 1 mem 0

2. Run the script till the report reaches 524,288

   python3 test.py & sleep 5

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 3 mem 524288 <-- (INTMAX + 1) >> PAGESHIFT

3. Kill the socket and confirm the number never drops

   pkill python3 && sleep 5

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 1 mem 524288

4. (necessary since v6.0) Trigger protomemorypcpu_drain()

   python3 test.py & sleep 1 && pkill python3

5. The number doubles

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 1 mem 1048577

The application set INTMAX to SORCVBUF, which triggered an integer overflow in udprmemrelease().

When a socket is close()d, udpdestructcommon() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable.

The total size is then passed to udprmemrelease() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow.

Then, the released amount is calculated as follows:

1) Add size to sk->skforwardalloc. 2) Round down sk->skforwardalloc to the nearest lower multiple of PAGESIZE and assign it to amount. 3) Subtract amount from sk->skforwardalloc. 4) Pass amount >> PAGESHIFT to _skmemreduceallocated().

When the issue occurred, the total in udpdestructcommon() was 2147484480 (INTMAX + 833), which was cast to -2147482816 in udprmem_release().

At 1) sk->skforwardalloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inetsockdestruct(). However, udpmemoryallocated ends up doubling at 4).

Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memoryallocated"), memory usage no longer doubles immediately after a socket is close()d because _skmemreduceallocated() caches the amount in udpmemorypercpufwalloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double.

This issue makes further memory allocation fail once the socket's sk->skrmemalloc exceeds net.ipv4.udprmemmin, resulting in packet drops.

To prevent this issue, let's use unsigned int for the calculation and call skforwardalloc_add() only once for the small delta.

Note that firstpacketlength() also potentially has the same problem.

SORCVBUFFORCE = 33 INTMAX = (2 ** 31) - 1

s = socket(AFINET, SOCKDGRAM) s.bind(('', 0)) s.setsockopt(SOLSOCKET, SORCVBUFFORCE, INT_MAX)

c = socket(AFINET, SOCKDGRAM) c.connect(s.getsockname())

data = b'a' * 100

while True: c.send(data)(CVE-2025-22058)

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

sctp: add mutual exclusion in procsctpdoudpport()

We must serialize calls to sctpudpsockstop() and sctpudpsockstart() or risk a crash as syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernelsockshutdown+0x47/0x70 net/socket.c:3653 Call Trace: <TASK> udptunnelsockrelease+0x68/0x80 net/ipv4/udptunnelcore.c:181 sctpudpsockstop+0x71/0x160 net/sctp/protocol.c:930 procsctpdoudpport+0x264/0x450 net/sctp/sysctl.c:553 procsyscallhandler+0x3d0/0x5b0 fs/proc/procsysctl.c:601 iterfilesplicewrite+0x91c/0x1150 fs/splice.c:738 dosplicefrom fs/splice.c:935 [inline] directspliceactor+0x18f/0x6c0 fs/splice.c:1158 splicedirecttoactor+0x342/0xa30 fs/splice.c:1102 dosplicedirectactor fs/splice.c:1201 [inline] dosplicedirect+0x174/0x240 fs/splice.c:1227 dosendfile+0xafd/0xe50 fs/readwrite.c:1368 _dosyssendfile64 fs/readwrite.c:1429 [inline] _sesyssendfile64 fs/readwrite.c:1415 [inline] _x64syssendfile64+0x1d8/0x220 fs/readwrite.c:1415 dosyscallx64 arch/x86/entry/syscall64.c:63 inline

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

net: fix NULL pointer dereference in l3mdevl3rcv

When delete l3s ipvlan:

ip link del link eth0 ipvlan1 type ipvlan mode l3s

This may cause a null pointer dereference:

Call trace:
 ip_rcv_finish+0x48/0xd0
 ip_rcv+0x5c/0x100
 __netif_receive_skb_one_core+0x64/0xb0
 __netif_receive_skb+0x20/0x80
 process_backlog+0xb4/0x204
 napi_poll+0xe8/0x294
 net_rx_action+0xd8/0x22c
 __do_softirq+0x12c/0x354

This is because l3mdevl3rcv() visit dev->l3mdevops after ipvlanl3sunregister() assign the dev->l3mdevops to NULL. The process like this:

(CPU1)                     | (CPU2)
l3mdev_l3_rcv()            |
  check dev->priv_flags:   |
    master = skb->dev;     |
                           |
                           | ipvlan_l3s_unregister()
                           |   set dev->priv_flags
                           |   dev->l3mdev_ops = NULL;
                           |
  visit master->l3mdev_ops |

To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.(CVE-2025-22103)

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

net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.

SIOCBRDELIF is passed to devioctl() first and later forwarded to brioctl_call(), which causes unnecessary RTNL dance and the splat below [0] under RTNL pressure.

Let's say Thread A is trying to detach a device from a bridge and Thread B is trying to remove the bridge.

In devioctl(), Thread A bumps the bridge device's refcnt by netdevhold() and releases RTNL because the following brioctlcall() also re-acquires RTNL.

In the race window, Thread B could acquire RTNL and try to remove the bridge device. Then, rtnlunlock() by Thread B will release RTNL and wait for netdevput() by Thread A.

Thread A, however, must hold RTNL after the unlock in dev_ifsioc(), which may take long under RTNL pressure, resulting in the splat by Thread B.

Thread A (SIOCBRDELIF) Thread B (SIOCBRDELBR) ---------------------- ---------------------- sockioctl sockioctl - sock_do_ioctl- brioctlcall - dev_ioctl- brioctlstub |- rtnllock | |- devifsioc ' ' |- dev = _devgetbyname(...) |- netdevhold(dev, ...) . / |- rtnlunlock ------. | | |- brioctlcall ---> |- rtnl_lock Race | |- brioctlstub |- brdelbridge Window | | | |- dev = _devgetbyname(...) | | | May take long | - br_dev_delete(dev, ...) | | | under RTNL pressure |- unregisternetdevicequeue(dev, ...) | | | | - rtnl_unlock \ | |- rtnl_lock <-'- netdevruntodo | |- ... - netdev_run_todo |- rtnlunlock |- _rtnlunlock | |- netdevwaitallrefsany |- netdev_put(dev, ...) <----------------' Wait refcnt decrement and log splat below

To avoid blocking SIOCBRDELBR unnecessarily, let's not call dev_ioctl() for SIOCBRADDIF and SIOCBRDELIF.

In the dev_ioctl() path, we do the following:

1. Copy struct ifreq by getuserifreq in sockdoioctl()
2. Check CAPNETADMIN in dev_ioctl()
3. Call devload() in devioctl()

4. Fetch the master dev from ifr.ifrname in devifsioc()

   3. can be done by requestmodule() in brioctlcall(), so we move 1., 2., and 4. to brioctl_stub().

Note that 2. is also checked later in adddelif(), but it's better performed before RTNL.

SIOCBRADDIF and SIOCBRDELIF have been processed in dev_ioctl() since the pre-git era, and there seems to be no specific reason to process them there.

reftracker: wpan3@ffff8880662d8608 has 1/1 users at _netdevtrackeralloc include/linux/netdevice.h:4282 [inline] netdevhold include/linux/netdevice.h:4311 [inline] devifsioc+0xc6a/0x1160 net/core/devioctl.c:624 devioctl+0x255/0x10c0 net/core/devioctl.c:826 sockdoioctl+0x1ca/0x260 net/socket.c:1213 sockioctl+0x23a/0x6c0 net/socket.c:1318 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:906 [inline] _sesysioctl fs/ioctl.c:892 [inline] _x64sysioctl+0x1a4/0x210 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcb/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2025-22111)

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

sctp: detect and prevent references to a freed transport in sendmsg

sctpsendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctpsendmsgtoasoc() sets the selected transport in all the message chunks to be sent.

There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTPSOCKOPTBINDXREM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctpwaitforsndbuf().

This causes the access to the transport data in sctpoutqselect_transport(), when the association outqueue is flushed, to result in a use-after-free read.

This change avoids this scenario by having sctptransportfree() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctptransport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctptransport").

Then, in the scenario where the sender thread has released the socket lock in sctpwaitfor_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process.

If the transport was deleted while the socket lock was relinquished, sctpsendmsgto_asoc() will return -EAGAIN to let userspace retry the send.

The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).(CVE-2025-23142)

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

net: stmmac: Fix accessing freed irq affinity_hint

The cpumask should not be a local variable, since its pointer is saved to irqdesc and may be accessed from procfs. To fix it, use the persistent mask cpumaskof(cpu#).(CVE-2025-23155)

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

tipc: fix memory leak in tipclinkxmit

In case the backlog transmit queue for system-importance messages is overloaded, tipclinkxmit() returns -ENOBUFS but the skb list is not purged. This leads to memory leak and failure when a skb is allocated.

This commit fixes this issue by purging the skb list before tipclinkxmit() returns.(CVE-2025-37757)

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

net: dsa: free routing table on probe failure

If complete = true in dsatreesetup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path.

After "complete" becomes true, dsatreesetupcpuports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV.

If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsalinktouch(), will remain there, and will lead to use-after-free if dereferenced.

If dsatreesetupswitches() returns -EPROBEDEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this:

================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxxsetupupstream_port+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42

Call trace: _asanreportload8noabort+0x20/0x30 mv88e6xxxsetupupstreamport+0x240/0x568 mv88e6xxxsetup+0xebc/0x1eb0 dsaregisterswitch+0x1af4/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 _driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 _deviceattach_driver+0x274/0x350

Allocated by task 42: _kasankmalloc+0x84/0xa0 _kmalloccachenoprof+0x298/0x490 dsaswitchtouchports+0x174/0x3d8 dsaregisterswitch+0x800/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 _driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 _deviceattach_driver+0x274/0x350

Freed by task 42: _kasanslabfree+0x48/0x68 kfree+0x138/0x418 dsaregisterswitch+0x2694/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 _driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 _deviceattachdriver+0x274/0x350

The simplest way to fix the bug is to delete the routing table in its entirety. dsatreesetuproutingtable() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsalinktouch() first checks whether the port pair already exists in dst->rtable, allocating if not.

The deletion of the routing table in its entirety already exists in dsatreeteardown(), so refactor that into a function that can also be called from the tree setup error path.

In my analysis of the commit to blame, it is the one which added dsa_link elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.(CVE-2025-37786)

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

net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registered

Russell King reports that a system with mv88e6xxx dereferences a NULL pointer when unbinding this driver: https://lore.kernel.org/netdev/(CVE-2025-37787)

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

cxgb4: fix memory leak in cxgb4initethtool_filters() error path

In the for loop used to allocate the locarray and bmap for each port, a memory leak is possible when the allocation for locarray succeeds, but the allocation for bmap fails. This is because when the control flow goes to the label freeethfinfo, only the allocations starting from (i-1)th iteration are freed.

Fix that by freeing the loc_array in the bmap allocation error path.(CVE-2025-37788)

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

net: mctp: Set SOCKRCUFREE

Bind lookup runs under RCU, so ensure that a socket doesn't go away in the middle of a lookup.(CVE-2025-37790)

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

net_sched: hfsc: Fix a UAF vulnerability in class handling

This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfscchangeclass() when working with certain child qdiscs like netem or codel.

The vulnerability works as follows: 1. hfscchangeclass() checks if a class has packets (q.qlen != 0) 2. It then calls qdiscpeeklen(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free

The fix adds a second queue length check after qdiscpeeklen() to verify the queue wasn't emptied.(CVE-2025-37797)

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

mcb: fix a double free bug in chameleonparsegdd()

In chameleonparsegdd(), if mcbdeviceregister() fails, 'mdev' would be released in mcbdeviceregister() via putdevice(). Thus, goto 'err' label and free 'mdev' again causes a double free. Just return if mcbdevice_register() fails.(CVE-2025-37817)

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

xen-netfront: handle NULL returned by xdpconvertbufftoframe()

The function xdpconvertbufftoframe() may return NULL if it fails to correctly convert the XDP buffer into an XDP frame due to memory constraints, internal errors, or invalid data. Failing to check for NULL may lead to a NULL pointer dereference if the result is used later in processing, potentially causing crashes, data corruption, or undefined behavior.

On XDP redirect failure, the associated page must be released explicitly if it was previously retained via get_page(). Failing to do so may result in a memory leak, as the pages reference count is not decremented.(CVE-2025-37820)

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

netsched: hfsc: Fix a potential UAF in hfscdequeue() too

Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.(CVE-2025-37823)

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

tipc: fix NULL pointer dereference in tipcmonreinit_self()

syzbot reported:

tipc: Node number set to 1055423674 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events tipcnetfinalizework RIP: 0010:tipcmonreinitself+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tipcnetfinalize+0x10b/0x180 net/tipc/net.c:140 processonework+0x9cc/0x1b70 kernel/workqueue.c:3238 processscheduledworks kernel/workqueue.c:3319 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 retfromfork+0x45/0x80 arch/x86/kernel/process.c:153 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK> ... RIP: 0010:tipcmonreinitself+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

There is a racing condition between workqueue created when enabling bearer and another thread created when disabling bearer right after that as follow:

enablingbearer | disablingbearer --------------- | ---------------- tipcdisctimeout() | { | bearerdisable() ... | { schedulework(&tn->work); | tipcmondelete() ... | { } | ... | writelockbh(&mon->lock); | mon->self = NULL; | writeunlockbh(&mon->lock); | ... | } tipcnetfinalizework() | } { | ... | tipcnetfinalize() | { | ... | tipcmonreinitself() | { | ... | writelockbh(&mon->lock); | mon->self->addr = tipcownaddr(net); | writeunlockbh(&mon->lock); | ...
---truncated---(CVE-2025-37824)

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

net: dsa: clean up FDB, MDB, VLAN entries on unbind

As explained in many places such as commit b117e1e8a86d ("net: dsa: delete dsalegacyfdbadd and dsalegacyfdbdel"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present.

But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit).

Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsaswitchsupportsucfiltering().

Although in tools/testing/selftests/net/forwarding/localtermination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user space - namely macvlan for unicast, and setsockopt(IPADD_MEMBERSHIP) - through mtools - for multicast, the fact is that 'bridge fdb add ... self static local' also exists as kernel UAPI, and might be useful to someone, even if only for a quick hack.

It seems counter-productive to block that path by implementing shim .ndofdbadd and .ndofdbdel operations which just return -EOPNOTSUPP in order to prevent the ndodfltfdbadd() and ndodfltfdbdel() from running, although we could do that.

Accepting that cleanup is necessary seems to be the only option. Especially since we appear to be coming back at this from a different angle as well. Russell King is noticing that the WARN_ON() triggers even for VLANs: https://lore.kernel.org/netdev/(CVE-2025-37864)

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

net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported

Russell King reports that on the ZII dev rev B, deleting a bridge VLAN from a user port fails with -ENOENT: https://lore.kernel.org/netdev/(CVE-2025-37865)

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

net: pktgen: fix access outside of user given buffer in pktgenthreadwrite()

Honour the user given buffer size for the strnlen() calls (otherwise strnlen() will access memory outside of the user given buffer).(CVE-2025-38061)

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

scsi: target: iscsi: Fix timeout on deleted connection

NOPIN response timer may expire on a deleted connection and crash with such logs:

Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d

BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsitfillcxntimeouterrstats+0x5c/0xc0 [iscsitargetmod] Call Trace: iscsithandlenopinresponsetimeout+0xfc/0x120 [iscsitargetmod] calltimerfn+0x58/0x1f0 runtimersoftirq+0x740/0x860 _dosoftirq+0x16c/0x420 irqexit+0x188/0x1c0 timer_interrupt+0x184/0x410

That is because nopin response timer may be re-started on nopin timer expiration.

Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started.(CVE-2025-38075)

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

crypto: algifhash - fix double free in hashaccept

If accept(2) is called on socket type algifhash with MSGMORE flag set and cryptoahashimport fails, sk2 is freed. However, it is also freed in afalgrelease, leading to slab-use-after-free error.(CVE-2025-38079)

A vulnerability was found in Linux Kernel (Operating System) and classified as problematic.The manipulation of the argument bNumDescriptors with an unknown input leads to a unknown weakness. Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.Impacted is confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 7a6d6b68db128da2078ccd9a751dfa3f75c9cf5b/41827a2dbdd7880df9881506dee13bc88d4230bb/1df80d748f984290c895e843401824215dcfbfb0/a8f842534807985d3a676006d140541b87044345/4fa7831cf0ac71a0a345369d1a6084f2b096e55e/74388368927e9c52a69524af5bbd6c55eb4690de/485e1b741eb838cbe1d6b0e81e5ab62ae6c095cf/fe7f7ac8e0c708446ff017453add769ffc15deed is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38103)

A vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38115)

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.93/6.12.33/6.15.2/6.16-rc1 (Operating System).Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch bdd56875c6926d8009914f427df71797693e90d4/4e83f2dbb2bf677e614109df24426c4dded472d4/d7882db79135c829a922daf3571f33ea1e056ae3/6fe26f694c824b8a4dbf50c635bee1302e3f099c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38117)

A vulnerability, which was classified as problematic, was found in Linux Kernel up to 8058c88ac0df21239daee54b5934d5c80ca9685f (Operating System).CWE is classifying the issue as CWE-401. The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.This is going to have an impact on confidentiality.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch b5ad58285f9217d68cd5ea2ad86ce254a3fe7c4d/90bc7f5a244aadee4292b28098b7c98aadd4b3aa/39bab2d3517b5b50c609b4f8c66129bf619fffa0/251496ce1728c9fd47bd2b20a7b21b20b9a020ca/8068e1e42b46518ce680dc6470bcd710efc3fa0a/ea77c397bff8b6d59f6d83dae1425b08f465e8b5 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38120)

A vulnerability classified as problematic has been found in Linux Kernel (Operating System).This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 0e65f38bd1aa14ea86e221b7bb814d38278d86c3/85eef1748c024da1a191aed56b30a3a65958c50c/4399f59a9467a324ed46657555f0e1f209a14acb/a04302867094bdc6efac1b598370fc47cf3f2388/3382a1ed7f778db841063f5d7e317ac55f9e7f72 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38124)

A vulnerability, which was classified as problematic, has been found in Linux Kernel up to 6.6.93/6.12.33/6.15.2 (Operating System).Using CWE to declare the problem leads to CWE-371.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 1d3c5d0dec6797eca3a861dab0816fa9505d9c3e/276849954d7cbe6eec827b21fe2df43f9bf07011/0e061abaad1498c5b76c10c594d4359ceb6b9145/0153f36041b8e52019ebfa8629c13bf8f9b0a951 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38127)

A vulnerability has been found in Linux Kernel up to 6.15.2 (Operating System) and classified as problematic.The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch e5ce9df1d68094d37360dbd9b09289d42fa21e54/7ee3fb6258da8c890a51b514f60d7570dc703605/40471b23147c86ea3ed97faee79937c618250bd0/5482ef9875eaa43f0435e14570e1193823de857e/ee5ee646385f5846dcbc881389f3c44a197c402a/5a85c21f812e02cb00ca07007d88acdd42d08c46/ac4e317a95a1092b5da5b9918b7118759342641c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19787).(CVE-2025-38157)

A vulnerability classified as problematic was found in Linux Kernel up to 6.15.3 (Operating System).As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch d9a55869d8237e677ddaa18b0f58586364cfbc1c/1f6332872374b7f482fc4ad865f9422fedb587fc/fbfe8446cd3274b9e367f5708d94574230a44409/5018d035530b6fbfad33eeb1dd1bc87da419a276/a87cbcc909ccfd394d4936a94663f586453d0961/aaa644e7ffff02e12c89cbce4753bc0b6f23ff87/d14cbed4baccd712447fb3f9c011f008b56b2097/42cb74a92adaf88061039601ddf7c874f58b554e is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20037).(CVE-2025-38219)

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3 (Operating System).Using CWE to declare the problem leads to CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.Impacted is availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch cf6a4c4ac7b6e3214f25df594c9689a62f1bb456/be5f3061a6f904e3674257879e71881ceee5b673/d7af6eee8cd60f55aa8c5fe2b91f11ec0c9a0f27/e26268ff1dcae5662c1b96c35f18cfa6ab73d9de is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20036).(CVE-2025-38220)

Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel. This vulnerability originates from improper processing of composing size in vivid drivers, which may lead to over-bounds writing.(CVE-2025-38226)

A vulnerability, which was classified as problematic, was found in Linux Kernel up to 32700ecf8007e071d1ce4c78f65b85f46d05f32a (Operating System).The manipulation of the argument adxlcomponentcount with an unknown input leads to a unknown weakness. CWE is classifying the issue as CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.This is going to have an impact on confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 80bf28fd623d97dd4f4825fbbe9d736cec2afba3/a6ed3a6edff09c1187cc6ade7f5967bca2376a13/bf6a8502a5f4ff6e4d135d795945cdade49ec8b0/e8530ed3c0769a4d8f79c212715ec1cf277787f8/3f5d0659000923735350da60ad710f8c804544fe/a13e8343ffcff27af1ff79597ff7ba241e6d9471/31ef6f7c9aee3be78d63789653e92350f2537f93/20d2d476b3ae18041be423671a8637ed5ffd6958 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38298)

A vulnerability classified as critical was found in Linux Kernel up to 6.15.3 (Operating System).The CWE definition for the vulnerability is CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.As an impact it is known to affect availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch 5c1a34ff5b0bfdfd2f9343aa9b08d25df618bac5/ec669e5bf409f16e464bfad75f0ba039a45de29a/43d5e3bb5f1dcd91e30238ea0b59a5f77063f84e/23361b479f2700c00960d3ae9cdc8ededa762d47/2e7c64d7a92c031d016f11c8e8cb05131ab7b75a/f78b38af3540b4875147b7b884ee11a27b3dbf4c/a377996d714afb8d4d5f4906336f78510039da29/af98b0157adf6504fade79b3e6cb260c4ff68e37 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38337)