OESA-2025-1339

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

dma-debug: fix a possible deadlock on radix_lock

radixlock() shouldn't be held while holding dmahashentry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rqlock():

CPU0 CPU1 CPU2 dmafreeattrs() checkunmap() adddmaentry() _schedule() //out (A) rqlock() gethashbucket() (A) dmaentryhash checksync() (A) radixlock() (W) dmaentryhash dmaentryfree() (W) radixlock() // CPU2's one (W) rq_lock()

CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wakeallkswapd().

CPU2 situation can happen while perfeventtaskschedout() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends).

To remove this possible situation, call dmaentryfree() after puthashbucket() in check_unmap().(CVE-2024-47143)

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

dlm: fix possible lkb_resource null dereference

This patch fixes a possible null pointer dereference when this function is called from requestlock() as lkb->lkbresource is not assigned yet, only after validatelockargs() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded.

The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference.

In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.(CVE-2024-47809)

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

bcache: revert replacing ISERRORNULL with ISERR again

Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") leads a NULL pointer deference in cachesetflush().

1721 if (!ISERRORNULL(c->root)) 1722 listadd(&c->root->list, &c->btree_cache);

>From the above code in cachesetflush(), if previous registration code fails before allocating c->root, it is possible c->root is NULL as what it is initialized. _bchbtreenodealloc() never returns NULL but c->root is possible to be NULL at above line 1721.

This patch replaces ISERR() by ISERRORNULL() to fix this.(CVE-2024-48881)

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

vfio/pci: Properly hide first-in-list PCIe extended capability

There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCIEXTCAPIDMAX) or a capability that is intentionally chosen to be hidden from the user.

Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden.

The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list.

However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfiopcicoredevice->pciconfigmap is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfioconfigdorw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array.

Fix it by checking capid in vfioconfigdorw(), and if it is greater than PCIEXTCAPIDMAX, use an alternative struct permbits for direct read only access instead of the ecapperms array.

Note that this is safe since the above is the only case where capid can exceed PCIEXTCAPID_MAX (except for the special capabilities, which are already checked before).

[1]

WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfiopciconfig.c:1900 vfiopciconfigrw+0x395/0x430 [vfiopcicore] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? showregs+0x69/0x80 ? _warn+0x8d/0x140 ? vfiopciconfigrw+0x395/0x430 [vfiopcicore] ? reportbug+0x18f/0x1a0 ? handlebug+0x63/0xa0 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? vfiopciconfigrw+0x395/0x430 [vfiopcicore] ? vfiopciconfigrw+0x244/0x430 [vfiopcicore] vfiopcirw+0x101/0x1b0 [vfiopcicore] vfiopcicoreread+0x1d/0x30 [vfiopcicore] vfiodevicefopsread+0x27/0x40 [vfio] vfsread+0xbd/0x340 ? vfiodevicefopsunlioctl+0xbb/0x740 [vfio] ? _rseqhandlenotifyresume+0xa4/0x4b0 _x64syspread64+0x96/0xc0 x64syscall+0x1c3d/0x20d0 dosyscall64+0x4d/0x120 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2024-53214)

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

net: afcan: do not leave a dangling sk pointer in cancreate()

On error cancreate() frees the allocated sk object, but sockinit_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)

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

afpacket: avoid erroring out after sockinitdata() in packetcreate()

After sockinitdata() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)

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

netfilter: ipset: Hold module reference while requesting a module

User space may unload ipset.ko while it is itself requesting a set type backend module, leading to a kernel crash. The race condition may be provoked by inserting an mdelay() right after the nfnlunlock() call.(CVE-2024-56637)

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

tipc: Fix use-after-free of kernel socket in cleanup_bearer().

syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. 0

When bearerdisable() calls tipcudpdisable(), cleanup of the UDP kernel socket is deferred by work calling cleanupbearer().

tipcexitnet() waits for such works to finish by checking tipcnet(net)->wqcount. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.

Let's move the decrement after releasing the socket in cleanup_bearer().

 sk_alloc+0x438/0x608
 inet_create+0x4c8/0xcb0
 __sock_create+0x350/0x6b8
 sock_create_kern+0x58/0x78
 udp_sock_create4+0x68/0x398
 udp_sock_create+0x88/0xc8
 tipc_udp_enable+0x5e8/0x848
 __tipc_nl_bearer_enable+0x84c/0xed8
 tipc_nl_bearer_enable+0x38/0x60
 genl_family_rcv_msg_doit+0x170/0x248
 genl_rcv_msg+0x400/0x5b0
 netlink_rcv_skb+0x1dc/0x398
 genl_rcv+0x44/0x68
 netlink_unicast+0x678/0x8b0
 netlink_sendmsg+0x5e4/0x898
 ____sys_sendmsg+0x500/0x830

BUG: KMSAN: use-after-free in udplibunhash+0x3b8/0x930 net/ipv4/udp.c:1979 udphashslot include/net/udp.h:85 [inline] udplibunhash+0x3b8/0x930 net/ipv4/udp.c:1979 skcommonrelease+0xaf/0x3f0 net/core/sock.c:3820 inetrelease+0x1e0/0x260 net/ipv4/afinet.c:437 inet6release+0x6f/0xd0 net/ipv6/afinet6.c:489 _sockrelease net/socket.c:658 [inline] sockrelease+0xa0/0x210 net/socket.c:686 cleanupbearer+0x42d/0x4c0 net/tipc/udpmedia.c:819 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xcaf/0x1c90 kernel/workqueue.c:3310 workerthread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 retfromfork+0x60/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry_64.S:244

Uninit was created at: slabfreehook mm/slub.c:2269 [inline] slabfree mm/slub.c:4580 [inline] kmemcachefree+0x207/0xc40 mm/slub.c:4682 netfree net/core/netnamespace.c:454 [inline] cleanupnet+0x16f2/0x19d0 net/core/netnamespace.c:647 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xcaf/0x1c90 kernel/workqueue.c:3310 workerthread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 retfromfork+0x60/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry64.S:244

CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)

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

net: hsr: avoid potential out-of-bound access in fillframeinfo()

syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one.

Since fillframeinfo() is relying on skb->mac_len already, extend the check to cover this case.

BUG: KMSAN: uninit-value in fillframeinfo net/hsr/hsrforward.c:709 [inline] BUG: KMSAN: uninit-value in hsrforwardskb+0x9ee/0x3b10 net/hsr/hsrforward.c:724 fillframeinfo net/hsr/hsrforward.c:709 [inline] hsrforwardskb+0x9ee/0x3b10 net/hsr/hsrforward.c:724 hsrdevxmit+0x2f0/0x350 net/hsr/hsrdevice.c:235 _netdevstartxmit include/linux/netdevice.h:5002 [inline] netdevstartxmit include/linux/netdevice.h:5011 [inline] xmitone net/core/dev.c:3590 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3606 _devqueuexmit+0x366a/0x57d0 net/core/dev.c:4434 devqueuexmit include/linux/netdevice.h:3168 [inline] packetxmit+0x9c/0x6c0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3146 [inline] packetsendmsg+0x91ae/0xa6f0 net/packet/afpacket.c:3178 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg+0x30f/0x380 net/socket.c:726 _syssendto+0x594/0x750 net/socket.c:2197 _dosyssendto net/socket.c:2204 [inline] _sesyssendto net/socket.c:2200 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2200 x64syscall+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls64.h:45 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:4091 [inline] slaballocnode mm/slub.c:4134 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4186 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:587 _allocskb+0x363/0x7b0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1323 [inline] allocskbwithfrags+0xc8/0xd00 net/core/skbuff.c:6612 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2881 packetallocskb net/packet/afpacket.c:2995 [inline] packetsnd net/packet/afpacket.c:3089 [inline] packetsendmsg+0x74c6/0xa6f0 net/packet/afpacket.c:3178 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg+0x30f/0x380 net/socket.c:726 _syssendto+0x594/0x750 net/socket.c:2197 _dosyssendto net/socket.c:2204 [inline] _sesyssendto net/socket.c:2200 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2200 x64syscall+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls64.h:45 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-56648)

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

usb: gadget: userial: Fix the issue that gsstart_io crashed due to accessing null pointer

Considering that in some extreme cases, when userial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gsopen, Thread B is executing the disconnect operation and calling the gserialdisconnect function,The port->portusb pointer will be set to NULL.

E.g. Thread A Thread B gsopen() gadgetunbinddriver() gsstartio() compositedisconnect() gsstartrx() gserialdisconnect() ... ... spinunlock(&port->portlock) status = usbepqueue() spinlock(&port->portlock) spinlock(&port->portlock) port->portusb = NULL gsfreerequests(port->portusb->in) spinunlock(&port->port_lock) Crash

This causes thread A to access a null pointer (port->portusb is null) when calling the gsfree_requests function, causing a crash.

If portusb is NULL, the release request will be skipped as it will be done by gserialdisconnect.

So add a null pointer check to gsstartio before attempting to access the value of the pointer port->port_usb.

Call trace: gsstartio+0x164/0x25c gsopen+0x108/0x13c ttyopen+0x314/0x638 chrdevopen+0x1b8/0x258 dodentryopen+0x2c4/0x700 vfsopen+0x2c/0x3c pathopenat+0xa64/0xc60 dofilpopen+0xb8/0x164 dosysopenat2+0x84/0xf0 _arm64sysopenat+0x70/0x9c invokesyscall+0x58/0x114 el0svccommon+0x80/0xe0 doel0svc+0x1c/0x28 el0svc+0x38/0x68(CVE-2024-56670)

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

9p/xen: fix release of IRQ

Kernel logs indicate an IRQ was double-freed.

Pass correct device ID during IRQ release.

Dominique: remove confusing variable reset to 0

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

netfilter: nftsocket: remove WARNON_ONCE on maximum cgroup level

cgroup maximum depth is INTMAX by default, there is a cgroup toggle to restrict this maximum depth to a more reasonable value not to harm performance. Remove unnecessary WARNON_ONCE which is reachable from userspace.(CVE-2024-56783)

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

MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a

Fix the dtc warnings:

arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'

And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"):

WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0

The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), which has fixed the issue for ls2k (despite its subject mentions ls7a).(CVE-2024-56785)

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

s390/entry: Mark IRQ entries to fix stack depot warnings

The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot.

Filtering uses inirqentrytext() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved.

While _dosoftirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific.

Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like:

Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depotallocstack+0x39a/0x3c8

with PREEMPT and KASAN enabled.

Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section.

This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value.

SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing.

IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies.(CVE-2024-57838)

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

drm/dp_mst: Fix resetting msg rx state after topology removal

If the MST topology is removed during the reception of an MST down reply or MST up request sideband message, the drmdpmsttopologymgr::upreqrecv/downreprecv states could be reset from one thread via drmdpmsttopologymgrsetmst(false), racing with the reading/parsing of the message from another thread via drmdpmsthandledownrep() or drmdpmsthandleupreq(). The race is possible since the reader/parser doesn't hold any lock while accessing the reception state. This in turn can lead to a memory corruption in the reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST sideband message body length check").

Fix the above by resetting the message reception state if needed before reading/parsing a message. Another solution would be to hold the drmdpmsttopologymgr::lock for the whole duration of the message reception/parsing in drmdpmsthandledownrep() and drmdpmsthandleupreq(), however this would require a bigger change. Since the fix is also needed for stable, opting for the simpler solution in this patch.(CVE-2024-57876)

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

rdma/cxgb4: Prevent potential integer overflow on 32bit

The "gl->totlen" variable is controlled by the user. It comes from processresponses(). On 32bit systems, the "gl->totlen + sizeof(struct cplpassacceptreq) + sizeof(struct rssheader)" addition could have an integer wrapping bug. Use sizeadd() to prevent this.(CVE-2024-57973)

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

media: imx-jpeg: Fix potential error pointer dereference in detach_pm()

The proble is on the first line:

if (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i]))

If jpeg->pddev[i] is an error pointer, then passing it to pmruntimesuspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the ISERRORNULL() check for that.(CVE-2024-57978)

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

HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections

A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop in hidapplymultiplier."), but the other has not been fixed.

This error arises because hidapplymultipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying:

 * "The Resolution Multiplier control must be contained in the same
 * Logical Collection as the control(s) to which it is to be applied.
   ...
 *  If no Logical Collection is
 * defined, the Resolution Multiplier is associated with all
 * controls in the report."
 * HID Usage Table, v1.12, Section 4.3.1, p30
 *
 * Thus, search from the current collection upwards until we find a
 * logical collection...

The comment and the code overlook the possibility that none of the collections found may be a Logical Collection.

The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.(CVE-2024-57986)

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

HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check

syzbot has found a type mismatch between a USB pipe and the transfer endpoint, which is triggered by the hid-thrustmaster driver[1]. There is a number of similar, already fixed issues [2]. In this case as in others, implementing check for endpoint type fixes the issue.

[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470 [2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622(CVE-2024-57993)

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

wifi: wcn36xx: fix channel survey memory allocation size

KASAN reported a memory allocation issue in wcn->chansurvey due to incorrect size calculation. This commit uses kcalloc to allocate memory for wcn->chansurvey, ensuring proper initialization and preventing the use of uninitialized values when there are no frames on the channel.(CVE-2024-57997)

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

OPP: add index check to assert to avoid buffer overflow in readfreq()

Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: devpmoppfindfreqexactindexed() or devpmoppfindfreqceil/floorindexed().

Add a secondary parameter to the assert function, unused for assertsingleclk() then add assertclkindex() which will check for the clock index when called from the _indexed() find functions.(CVE-2024-57998)

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

PCI: dwc: ep: Prevent changing BAR size/flags in pciepcset_bar()

In commit 4284c88fff0e ("PCI: designware-ep: Allow pciepcsetbar() update inbound map address") setbar() was modified to support dynamically changing the backing physical address of a BAR that was already configured.

This means that setbar() can be called twice, without ever calling clearbar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host).

This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks.

If we allow setbar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pciepf_bar.

While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.)(CVE-2024-58006)

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

memory: tegra20-emc: fix an OF node reference bug in tegraemcfindnodebyramcode()

As offindnodebyname() release the reference of the argument device node, tegraemcfindnodebyramcode() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the foreachchildofnode() macro and ofgetchildbyname() instead of offindnodebyname() to simplify the code.

This bug was found by an experimental verification tool that I am developing.

krzysztof: applied v1, adjust the commit msg to incorporate v2 parts

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

ipmi: ipmb: Add check devm_kasprintf() returned value

devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.(CVE-2024-58051)

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

drm/amdgpu: Fix potential NULL pointer dereference in atomctrlgetsmcsclkrange_table

The function atomctrlgetsmcsclkrangetable() does not check the return value of smuatomgetdatatable(). If smuatomgetdatatable() fails to retrieve SMUInfo table, it returns NULL which is later dereferenced.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.(CVE-2024-58052)

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

rxrpc: Fix handling of received connection abort

Fix the handling of a connection abort that we've received. Though the abort is at the connection level, it needs propagating to the calls on that connection. Whilst the propagation bit is performed, the calls aren't then woken up to go and process their termination, and as no further input is forthcoming, they just hang.

Also add some tracing for the logging of connection aborts.(CVE-2024-58053)

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

staging: media: max96712: fix kernel oops when removing module

The following kernel oops is thrown when trying to remove the max96712 module:

Unable to handle kernel paging request at virtual address 00007375746174db Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: crct10difce polyvalce mxcjpegencdec flexcan sndsocfslsai sndsocfslasoccard sndsocfslmicfil dwcmipicsi2 imxcsiformatter polyvalgeneric v4l2jpeg imxpcmdma candev sndsocimxaudmux sndsocwm8962 sndsocimxcard sndsocfslutils max96712(C-) rpmsgctrl rpmsgchar pwmfan fuse [last unloaded: imx8isi] CPU: 0 UID: 0 PID: 754 Comm: rmmod Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17 Tainted: [C]=CRAP Hardware name: NXP i.MX95 19X19 board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ledput+0x1c/0x40 lr : v4l2subdevputprivacyled+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace: ledput+0x1c/0x40 v4l2subdevputprivacyled+0x48/0x58 v4l2asyncunregistersubdev+0x2c/0x1a4 max96712remove+0x1c/0x38 [max96712] i2cdeviceremove+0x2c/0x9c deviceremove+0x4c/0x80 devicereleasedriverinternal+0x1cc/0x228 driverdetach+0x4c/0x98 busremovedriver+0x6c/0xbc driverunregister+0x30/0x60 i2cdeldriver+0x54/0x64 max96712i2cdriverexit+0x18/0x1d0 [max96712] _arm64sysdeletemodule+0x1a4/0x290 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0xc0/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0xd8 el0t64synchandler+0x120/0x12c el0t64sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]---

This happens because in v4l2i2csubdevinit(), the i2csetcliendata() is called again and the data is overwritten to point to sd, instead of priv. So, in remove(), the wrong pointer is passed to v4l2asyncunregistersubdev(), leading to a crash.(CVE-2024-58054)

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

remoteproc: core: Fix ida_free call while not allocated

In the rprocalloc() function, on error, putdevice(&rproc->dev) is called, leading to the call of the rproctyperelease() function. An error can occurs before ida_alloc is called.

In such case in rproctyperelease(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. idafree() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 idafree+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] idafree called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panelorisetechotm8009a dwmipidsistm(+) gpusched dwmipidsi stm32rproc stm32crc32 stm32ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: eventsunbound deferredprobeworkfunc [ 4.242504] Call trace: [ 4.242522] unwindbacktrace from showstack+0x10/0x14 [ 4.250218] showstack from dumpstacklvl+0x50/0x64 [ 4.255274] dumpstacklvl from _warn+0x80/0x12c [ 4.260134] _warn from warnslowpathfmt+0x114/0x188 [ 4.265199] warnslowpathfmt from idafree+0x100/0x164 [ 4.270565] idafree from rproctyperelease+0x38/0x60 [ 4.275832] rproctyperelease from devicerelease+0x30/0xa0 [ 4.281601] devicerelease from kobjectput+0xc4/0x294 [ 4.286762] kobjectput from rprocalloc.part.0+0x208/0x28c [ 4.292430] rprocalloc.part.0 from devmrprocalloc+0x80/0xc4 [ 4.298393] devmrprocalloc from stm32rprocprobe+0xd0/0x844 [stm32rproc] [ 4.305575] stm32rprocprobe [stm32rproc] from platformprobe+0x5c/0xbc

Calling idaalloc earlier in rprocalloc ensures that the rproc->index is properly set.(CVE-2024-58056)

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

ubifs: skip dumping tnc tree when zroot is null

Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.(CVE-2024-58058)

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

wifi: mac80211: prohibit deactivating all links

In the internal API this calls this is a WARN_ON, but that should remain since internally we want to know about bugs that may cause this. Prevent deactivating all links in the debugfs write directly.(CVE-2024-58061)

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

wifi: rtlwifi: fix memory leaks and invalid access at probe error path

Deinitialize at reverse order when probe fails.

When initswvars fails, rtldeinitcore should not be called, specially now that it destroys the rtl_wq workqueue.

And call rtlpcideinit and deinitswvars, otherwise, memory will be leaked.

Remove pcisetdrvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pcisetdrvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").(CVE-2024-58063)

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

OPP: fix devpmoppfindbw_*() when bandwidth table not initialized

If a driver calls devpmoppfindbw_ceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : readbw+0x8/0x10 lr : opptablefindkey+0x9c/0x174 ... Call trace: readbw+0x8/0x10 (P) opptablefindkey+0x9c/0x174 (L) findkey+0x98/0x168 devpmoppfindbw_ceil+0x50/0x88 ...

In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with readbw().(CVE-2024-58068)

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

team: prevent adding a device which is already a team device lower

Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1.

This is not useful in practice and can lead to recursive locking:

$ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0

============================================ WARNING: possible recursive locking detected

6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted

ip/7684 is trying to acquire lock: ffff888016848e00 (team->teamlockkey){+.+.}-{4:4}, at: teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/team_core.c:2973)

but task is already holding lock: ffff888016848e00 (team->teamlockkey){+.+.}-{4:4}, at: teamaddslave (drivers/net/team/teamcore.c:1147 drivers/net/team/teamcore.c:1977)

other info that might help us debug this: Possible unsafe locking scenario:

CPU0

lock(team->teamlockkey); lock(team->teamlockkey);

* DEADLOCK *

May be due to missing lock nesting notation

2 locks held by ip/7684:

stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:122) printdeadlockbug.cold (kernel/locking/lockdep.c:3040) _lockacquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlinkbroadcastfiltered (net/netlink/afnetlink.c:1548) lockacquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? tracelockacquire (./include/trace/events/lock.h:24 (discriminator 2)) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? lockacquire (kernel/locking/lockdep.c:5822) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) _mutexlock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? fibsyncup (net/ipv4/fibsemantics.c:2167) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) notifiercallchain (kernel/notifier.c:85) callnetdevicenotifiersinfo (net/core/dev.c:1996) _devnotifyflags (net/core/dev.c:8993) ? _devchangeflags (net/core/dev.c:8975) devchangeflags (net/core/dev.c:9027) vlandeviceevent (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? brdeviceevent (net/bridge/br.c:143) notifiercallchain (kernel/notifier.c:85) callnetdevicenotifiersinfo (net/core/dev.c:1996) devopen (net/core/dev.c:1519 net/core/dev.c:1505) teamaddslave (drivers/net/team/teamcore.c:1219 drivers/net/team/teamcore.c:1977) ? _pfxteamaddslave (drivers/net/team/teamcore.c:1972) dosetmaster (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)(CVE-2024-58071)

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

wifi: rtlwifi: remove unused checkbuddypriv

Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global list of private data structures.

Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") started adding the private data to that list at probe time and added a hook, checkbuddypriv to find the private data from a similar device.

However, that function was never used.

Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory.

Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.(CVE-2024-58072)

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

vfio/platform: check the bounds of read/write syscalls

count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)

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

mptcp: handle fastopen disconnect correctly

Syzbot was able to trigger a data stream corruption:

WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 mptcpcleanuna+0xddb/0xff0 net/mptcp/protocol.c:1024 Modules linked in: CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:mptcpcleanuna+0xddb/0xff0 net/mptcp/protocol.c:1024 Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 <0f> 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07 RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293 RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928 R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000 R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000 FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> mptcpcleanunawakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074 mptcpreleasecb+0x7cb/0xb30 net/mptcp/protocol.c:3493 releasesock+0x1aa/0x1f0 net/core/sock.c:3640 inetwaitforconnect net/ipv4/afinet.c:609 [inline] _inetstreamconnect+0x8bd/0xf30 net/ipv4/afinet.c:703 mptcpsendmsgfastopen+0x2a2/0x530 net/mptcp/protocol.c:1755 mptcpsendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg+0x1a6/0x270 net/socket.c:726 _syssendmsg+0x52a/0x7e0 net/socket.c:2583 _syssendmsg net/socket.c:2637 [inline] _syssendmsg+0x269/0x350 net/socket.c:2669 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f6e86ebfe69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69 RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508 </TASK>

The root cause is the bad handling of disconnect() generated internally by the MPTCP protocol in case of connect FASTOPEN errors.

Address the issue increasing the socket disconnect counter even on such a case, to allow other threads waiting on the same socket lock to properly error out.(CVE-2025-21705)

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

mptcp: consolidate suboption status

MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info.

Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption.

The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized:

BUG: KMSAN: uninit-value in _mptcpexpandseq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcpexpandseq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ackupdatemsk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcpincomingoptions+0x2036/0x3d30 net/mptcp/options.c:1209 _mptcpexpandseq net/mptcp/options.c:1030 [inline] mptcpexpandseq net/mptcp/protocol.h:864 [inline] ackupdatemsk net/mptcp/options.c:1060 [inline] mptcpincomingoptions+0x2036/0x3d30 net/mptcp/options.c:1209 tcpdataqueue+0xb4/0x7be0 net/ipv4/tcpinput.c:5233 tcprcvestablished+0x1061/0x2510 net/ipv4/tcpinput.c:6264 tcpv4dorcv+0x7f3/0x11a0 net/ipv4/tcpipv4.c:1916 tcpv4rcv+0x51df/0x5750 net/ipv4/tcpipv4.c:2351 ipprotocoldeliverrcu+0x2a3/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:314 [inline] iplocaldeliver+0x21f/0x490 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:460 [inline] iprcvfinish+0x4a2/0x520 net/ipv4/ipinput.c:447 NFHOOK include/linux/netfilter.h:314 [inline] iprcv+0xcd/0x380 net/ipv4/ipinput.c:567 _netifreceiveskbonecore net/core/dev.c:5704 [inline] _netifreceiveskb+0x319/0xa00 net/core/dev.c:5817 processbacklog+0x4ad/0xa50 net/core/dev.c:6149 _napipoll+0xe7/0x980 net/core/dev.c:6902 napipoll net/core/dev.c:6971 [inline] netrxaction+0xa5a/0x19b0 net/core/dev.c:7093 handlesoftirqs+0x1a0/0x7c0 kernel/softirq.c:561 _dosoftirq+0x14/0x1a kernel/softirq.c:595 dosoftirq+0x9a/0x100 kernel/softirq.c:462 _localbhenableip+0x9f/0xb0 kernel/softirq.c:389 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:919 [inline] _devqueuexmit+0x2758/0x57d0 net/core/dev.c:4493 devqueuexmit include/linux/netdevice.h:3168 [inline] neighhhoutput include/net/neighbour.h:523 [inline] neighoutput include/net/neighbour.h:537 [inline] ipfinishoutput2+0x187c/0x1b70 net/ipv4/ipoutput.c:236 _ipfinishoutput+0x287/0x810 ipfinishoutput+0x4b/0x600 net/ipv4/ipoutput.c:324 NFHOOKCOND include/linux/netfilter.h:303 [inline] ipoutput+0x15f/0x3f0 net/ipv4/ipoutput.c:434 dstoutput include/net/dst.h:450 [inline] iplocalout net/ipv4/ipoutput.c:130 [inline] _ipqueuexmit+0x1f2a/0x20d0 net/ipv4/ipoutput.c:536 ipqueuexmit+0x60/0x80 net/ipv4/ipoutput.c:550 _tcptransmitskb+0x3cea/0x4900 net/ipv4/tcpoutput.c:1468 tcptransmitskb net/ipv4/tcpoutput.c:1486 [inline] tcpwritexmit+0x3b90/0x9070 net/ipv4/tcpoutput.c:2829 _tcppushpendingframes+0xc4/0x380 net/ipv4/tcpoutput.c:3012 tcpsendfin+0x9f6/0xf50 net/ipv4/tcpoutput.c:3618 _tcpclose+0x140c/0x1550 net/ipv4/tcp.c:3130 _mptcpclosessk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcpclosessk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcppmnlrmaddrorsubflow+0x635/0xd10 net/mptcp/pmnetlink.c:889 mptcppmnlrmsubflowreceived net/mptcp/pmnetlink.c:924 [inline] mptcppmflushaddrsandsubflows net/mptcp/pmnetlink.c:1688 [inline] mptcpnlflushaddrslist net/mptcp/pmnetlink.c:1709 [inline] mptcppmnlflushaddrsdoit+0xe10/0x1630 net/mptcp/pmnetlink.c:1750 genlfamilyrcvmsg_doit net/netlink/genetlink.c:1115 [inline]

---truncated---(CVE-2025-21707)

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

net: usb: rtl8150: enable basic endpoint checking

Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below.

For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary.

[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usbsubmiturb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usbsubmiturb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rtl8150open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 _devopen+0x2d4/0x4e0 net/core/dev.c:1474 _devchangeflags+0x561/0x720 net/core/dev.c:8838 devchangeflags+0x8f/0x160 net/core/dev.c:8910 devinetioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inetioctl+0x3aa/0x3f0 net/ipv4/afinet.c:1003 sockdoioctl+0x116/0x280 net/socket.c:1222 sockioctl+0x22e/0x6c0 net/socket.c:1341 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl fs/ioctl.c:893 [inline] _x64sysioctl+0x193/0x220 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ...

This change has not been tested on real hardware.(CVE-2025-21708)

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

tcp: correct handling of extreme memory squeeze

Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations.

Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations.

However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution.

The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SOPEEK or SORCVBUF on the socket.

The following excerpt of a logging session, with own comments added, shows more in detail what is happening:

// tcpv4rcv(->) // tcprcvestablished(->) [rcvnxt 265600160, rcvwnd 262144, sntack 265469200, winnow 131184] [copiedseq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0] [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] [tp->rcvwup: 265469200, tp->rcvwnd: 262144, tp->rcvnxt 265600160] returning 0 // Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcvwnd and tp->rcv_wup accordingly, which means // we unconditionally shrink the window.

                [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
              [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
              [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]
              returning 6104 bytes

// After each read, the algorithm for calculating the new receive // window in _tcpcleanuprbuf() finds it is too small to advertise // or to update tp->rcvwnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side.

---truncated---(CVE-2025-21710)

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

net/rose: prevent integer overflows in rose_setsockopt()

In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur.

Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.(CVE-2025-21711)

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

net: davicom: fix UAF in dm9000drvremove

dm is netdev private data and it cannot be used after freenetdev() call. Using dm after freenetdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.

This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").

This bug is detected by our static analysis tool.(CVE-2025-21715)

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

vxlan: Fix uninit-value in vxlanvnifilterdump()

KMSAN reported an uninit-value access in vxlanvnifilterdump() [1].

If the length of the netlink message payload is less than sizeof(struct tunnelmsg), vxlanvnifilter_dump() accesses bytes beyond the message. This can lead to uninit-value access. Fix this by returning an error in such situations.

[1] BUG: KMSAN: uninit-value in vxlanvnifilterdump+0x328/0x920 drivers/net/vxlan/vxlanvnifilter.c:422 vxlanvnifilterdump+0x328/0x920 drivers/net/vxlan/vxlanvnifilter.c:422 rtnldumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786 netlinkdump+0x93e/0x15f0 net/netlink/afnetlink.c:2317 netlinkdumpstart+0x716/0xd60 net/netlink/afnetlink.c:2432 netlinkdumpstart include/linux/netlink.h:340 [inline] rtnetlinkdumpstart net/core/rtnetlink.c:6815 [inline] rtnetlinkrcvmsg+0x1256/0x14a0 net/core/rtnetlink.c:6882 netlinkrcvskb+0x467/0x660 net/netlink/afnetlink.c:2542 rtnetlinkrcv+0x35/0x40 net/core/rtnetlink.c:6944 netlinkunicastkernel net/netlink/afnetlink.c:1321 [inline] netlinkunicast+0xed6/0x1290 net/netlink/afnetlink.c:1347 netlinksendmsg+0x1092/0x1230 net/netlink/afnetlink.c:1891 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg+0x330/0x3d0 net/socket.c:726 _syssendmsg+0x7f4/0xb50 net/socket.c:2583 _syssendmsg+0x271/0x3b0 net/socket.c:2637 _syssendmsg net/socket.c:2669 [inline] _dosyssendmsg net/socket.c:2674 [inline] _sesyssendmsg net/socket.c:2672 [inline] _x64syssendmsg+0x211/0x3e0 net/socket.c:2672 x64syscall+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1d0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:4110 [inline] slaballocnode mm/slub.c:4153 [inline] kmemcacheallocnodenoprof+0x800/0xe80 mm/slub.c:4205 kmallocreserve+0x13b/0x4b0 net/core/skbuff.c:587 allocskb+0x347/0x7d0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1323 [inline] netlinkalloclargeskb+0xa5/0x280 net/netlink/afnetlink.c:1196 netlinksendmsg+0xac9/0x1230 net/netlink/afnetlink.c:1866 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg+0x330/0x3d0 net/socket.c:726 syssendmsg+0x7f4/0xb50 net/socket.c:2583 _syssendmsg+0x271/0x3b0 net/socket.c:2637 _syssendmsg net/socket.c:2669 [inline] _dosyssendmsg net/socket.c:2674 [inline] _sesyssendmsg net/socket.c:2672 [inline] _x64syssendmsg+0x211/0x3e0 net/socket.c:2672 x64syscall+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1d0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014(CVE-2025-21716)

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

xfrm: delete intermediate secpath entry in packet offload mode

Packets handled by hardware have added secpath as a way to inform XFRM core code that this path was already handled. That secpath is not needed at all after policy is checked and it is removed later in the stack.

However, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ipforward), that secpath is not removed and packets which already were handled are reentered to the driver TX path with xfrmoffload set.

The following kernel panic is observed in mlx5 in such case:

mlx5core 0000:04:00.0 enp4s0f0np0: Link up mlx5core 0000:04:00.1 enp4s0f1np1: Link up Initializing XFRM netlink socket IPsec XFRM device driver BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: errorcode(0x0010) - not-present page PGD 0 P4D 0 Oops: Oops: 0010 [#1] PREEMPT SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffb87380003800 EFLAGS: 00010206 RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00 RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010 R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00 R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0 Call Trace: <IRQ> ? showregs+0x63/0x70 ? _diebody+0x20/0x60 ? _die+0x2b/0x40 ? pagefaultoops+0x15c/0x550 ? douseraddrfault+0x3ed/0x870 ? excpagefault+0x7f/0x190 ? asmexcpagefault+0x27/0x30 mlx5eipsechandletxskb+0xe7/0x2f0 [mlx5core] mlx5exmit+0x58e/0x1980 [mlx5core] ? _fiblookup+0x6a/0xb0 devhardstartxmit+0x82/0x1d0 schdirectxmit+0xfe/0x390 _devqueuexmit+0x6d8/0xee0 ? _fiblookup+0x6a/0xb0 ? internaladdtimer+0x48/0x70 ? modtimer+0xe2/0x2b0 neighresolveoutput+0x115/0x1b0 _neighupdate+0x26a/0xc50 neighupdate+0x14/0x20 arpprocess+0x2cb/0x8e0 ? _napibuildskb+0x5e/0x70 arprcv+0x11e/0x1c0 ? devgroreceive+0x574/0x820 _netifreceiveskblistcore+0x1cf/0x1f0 netifreceiveskblistinternal+0x183/0x2a0 napicompletedone+0x76/0x1c0 mlx5enapipoll+0x234/0x7a0 [mlx5core] _napipoll+0x2d/0x1f0 netrxaction+0x1a6/0x370 ? atomicnotifiercallchain+0x3b/0x50 ? irqinthandler+0x15/0x20 [mlx5core] handlesoftirqs+0xb9/0x2f0 ? handleirqevent+0x44/0x60 irqexitrcu+0xdb/0x100 commoninterrupt+0x98/0xc0 </IRQ> <TASK> asmcommoninterrupt+0x27/0x40 RIP: 0010:pvnativesafehalt+0xb/0x10 Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb 40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8 RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680 RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4 RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70 R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40 R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8 ? defaultidle+0x9/0x20 archcpuidle+0x9/0x10 defaultidlecall+0x29/0xf0 doidle+0x1f2/0x240 cpustartupentry+0x2c/0x30 restinit+0xe7/0x100 startkernel+0x76b/0xb90 x8664startreservations+0x18/0x30 x8664startkernel+0xc0/0x110 ? setupghcb+0xe/0x130 commonstartup64+0x13e/0x141 </TASK> Modules linked in: esp4offload esp4 xfrminterface xfrm6tunnel tunnel4 tunnel6 xfrmuser xfrmalgo binf ---truncated---(CVE-2025-21720)

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

iommufd/iovabitmap: Fix shift-out-of-bounds in iovabitmapoffsetto_index()

Resolve a UBSAN shift-out-of-bounds issue in iovabitmapoffsettoindex() where shifting the constant "1" (of type int) by bitmap->mapped.pgshift (an unsigned long value) could result in undefined behavior.

The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds 31 (e.g., pgshift = 63) the shift operation overflows, as the result cannot be represented in a 32-bit type.

To resolve this, the constant is updated to "1UL", promoting it to an unsigned long type to match the operand's type.(CVE-2025-21724)

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

smb: client: fix oops due to unset link speed

It isn't guaranteed that NETWORKINTERFACEINFO::LinkSpeed will always be set by the server, so the client must handle any values and then prevent oopses like below from happening:

Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:cifsdebugdataprocshow+0xa45/0x1460 [cifs] Code: 00 00 48 89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8 e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 <48> f7 74 24 18 48 89 c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24 RSP: 0018:ffffc90001817be0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99 RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228 RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200 R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58 FS: 00007fe27119e740(0000) GS:ffff888148600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? _diebody.cold+0x19/0x27 ? die+0x2e/0x50 ? dotrap+0x159/0x1b0 ? cifsdebugdataprocshow+0xa45/0x1460 [cifs] ? doerrortrap+0x90/0x130 ? cifsdebugdataprocshow+0xa45/0x1460 [cifs] ? excdivideerror+0x39/0x50 ? cifsdebugdataprocshow+0xa45/0x1460 [cifs] ? asmexcdivideerror+0x1a/0x20 ? cifsdebugdataprocshow+0xa39/0x1460 [cifs] ? cifsdebugdataprocshow+0xa45/0x1460 [cifs] ? seqreaditer+0x42e/0x790 seqreaditer+0x19a/0x790 procregreaditer+0xbe/0x110 ? _pfxprocregreaditer+0x10/0x10 vfsread+0x469/0x570 ? douseraddrfault+0x398/0x760 ? _pfxvfsread+0x10/0x10 ? findheldlock+0x8a/0xa0 ? _pfxlockrelease+0x10/0x10 ksysread+0xd3/0x170 ? _pfxksysread+0x10/0x10 ? _rcureadunlock+0x50/0x270 ? markheldlocks+0x1a/0x90 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fe271288911 Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIGRAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911 RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003 RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000 </TASK>

Fix this by setting cifsserveriface::speed to a sane value (1Gbps) by default when link speed is unset.(CVE-2025-21725)

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

padata: avoid UAF for reorder_work

Although the previous patch can avoid ps and ps UAF for doserial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below:

cryptorequest cryptorequest cryptodelalg padatadoserial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }

            padata_do_serial
              // new request added
              list_add
// sees the new request
queue_work(reorder_work)
              padata_reorder
                queue_work_on(squeue->work)

...

            <kworker context>
            padata_serial_worker
            // completes new request,
            // no more outstanding
            // requests

                        crypto_del_alg
                          // free pd

<kworker context> invokepadatareorder // UAF of pd

To avoid UAF for 'reorderwork', get 'pd' ref before put 'reorderwork' into the 'serialwq' and put 'pd' ref until the 'serialwq' finish.(CVE-2025-21726)

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

padata: fix UAF in padata_reorder

A bug was found when run ltp test:

BUG: KASAN: slab-use-after-free in padatafindnext+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206

CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecryptparallel padataparallelworker Call Trace: <TASK> dumpstacklvl+0x32/0x50 printaddressdescription.constprop.0+0x6b/0x3d0 printreport+0xdd/0x2c0 kasanreport+0xa5/0xd0 padatafindnext+0x29/0x1a0 padatareorder+0x131/0x220 padataparallelworker+0x3d/0xc0 processonework+0x2ec/0x5a0

If 'mdelay(10)' is added before calling 'padatafindnext' in the 'padatareorder' function, this issue could be reproduced easily with ltp test (pcryptaead01).

This can be explained as bellow:

pcryptaeadencrypt ... padatadoparallel refcountinc(&pd->refcnt); // add refcnt ... padatadoserial padatareorder // pd while (1) { padatafindnext(pd, true); // using pd queueworkon ... padataserialworker cryptodelalg padataputpdcnt // sub refcnt padatafreeshell padataputpd(ps->pd); // pd is freed // loop again, but pd is freed // call padatafind_next, UAF }

In the padatareorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padatafind_next', which leads to UAF.

As mentioned in [1], doserial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronizercu() in 'padatafreeshell' wait for all doserial calls to finish.

[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)

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

bpf: Send signals asynchronously if !preemptible

BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpfsendsignal() kfunc, it will cause issues because this kfunc can sleep. Change irqs_disabled() to !preemptible().(CVE-2025-21728)

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

blk-cgroup: Fix class @block_class's subsystem refcount leakage

blkcgfillrootiostats() iterates over @blockclass's devices by classdeviter(init|next)(), but does not end iterating with classdeviterexit(), so causes the class's subsystem refcount leakage.

Fix by ending the iterating with classdeviter_exit().(CVE-2025-21745)

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

net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65cpswnussremovetx_chns()

When getting the IRQ we use k3udmagluetxget_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid.

There is no issue at probe time but at runtime user can invoke .setchannels which results in the following call chain. am65cpswsetchannels() am65cpswnussupdatetxrxchns() am65cpswnussremovetxchns() am65cpswnussinittxchns()

At this point if am65cpswnussinittxchns() fails due to k3udmagluetxgetirq() then tx_chn->irq will be set to a negative value.

Then, at subsequent .setchannels with higher channel count we will attempt to free an invalid IRQ in am65cpswnussremovetxchns() leading to a kernel warning.

The issue is present in the original commit that introduced this driver, although there, am65cpswnussupdatetxrxchns() existed as am65cpswnussupdatetx_chns().(CVE-2025-21799)

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

LoongArch: Fix warnings during S3 suspend

The enablegpewakeup() function calls acpienableallwakeupgpes(), and the later one may call the preemptschedulecommon() function, resulting in a thread switch and causing the CPU to be in an interrupt enabled state after the enablegpewakeup() function returns, leading to the warnings as follow.

[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktimeget+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] showstack+0x64/0x188 [ C0] [<900000000164673c>] dumpstacklvl+0x60/0x88 [ C0] [<90000000002687e4>] _warn+0x8c/0x148 [ C0] [<90000000015e9978>] reportbug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] dobp+0x204/0x3b8 [ C0] [<90000000025b1924>] exceptionhandlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktimeget+0xbc/0xc8 [ C0] [<9000000000354c08>] tickschedtimer+0x30/0xb0 [ C0] [<90000000003408e0>] _hrtimerrunqueues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimerinterrupt+0x144/0x388 [ C0] [<9000000000228348>] constanttimerinterrupt+0x38/0x48 [ C0] [<90000000002feba4>] _handleirqeventpercpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handleirqeventpercpu+0x20/0x80 [ C0] [<9000000000306b9c>] handlepercpuirq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generichandledomainirq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handlecpuirq+0x70/0xa8 [ C0] [<9000000001646b30>] handleloongarchirq+0x30/0x48 [ C0] [<9000000001646bc8>] dovint+0x80/0xe0 [ C0] [<90000000002aea1c>] finishtaskswitch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] _schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] workerthread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] retfromkernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]---

The root cause is acpienableallwakeupgpes() uses a mutex to protect acpihwenableallwakeupgpes(), and acpiutacquiremutex() may cause a thread switch. Since there is no longer concurrent execution during loongarchacpisuspend(), we can call acpihwenableallwakeupgpes() directly in enablegpe_wakeup().

The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid breaking S3 wakeup due to might_sleep()").(CVE-2025-21803)

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

PCI: rcar-ep: Fix incorrect variable used when calling devmrequestmem_region()

The rcarpcieparseoutboundranges() uses the devmrequestmem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior.

Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows:

$ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :

Sometimes, garbage may appear after the colon.

In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack.

Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows:

$ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3

kwilczynski: commit log

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

net: let net.core.dev_weight always be non-zero

The following problem was encountered during stability test:

(NULL netdevice): NAPI poll function processbacklog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ listadd double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/listdebug.c:35 \ listaddvalidorreport+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:listaddvalidorreport+0xf3/0x130 Call Trace: ? _warn+0xcd/0x250 ? _listaddvalidorreport+0xf3/0x130 enqueuetobacklog+0x923/0x1070 netifrxinternal+0x92/0x2b0 _netifrx+0x15/0x170 loopbackxmit+0x2ef/0x450 devhardstartxmit+0x103/0x490 _devqueuexmit+0xeac/0x1950 ipfinishoutput2+0x6cc/0x1620 ipoutput+0x161/0x270 ippushpendingframes+0x155/0x1a0 rawsendmsg+0xe13/0x1550 _syssendto+0x3bf/0x4e0 _x64syssendto+0xdc/0x1b0 dosyscall64+0x5b/0x170 entrySYSCALL64after_hwframe+0x76/0x7e

The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1

This is because when the napi's weight is set to 0, processbacklog() may return 0 and clear the NAPISTATESCHED bit of napi->state, causing this napi to be re-polled in netrxaction() until _dosoftirq() times out. Since the NAPISTATESCHED bit has been cleared, napischedulerps() can be retriggered in enqueueto_backlog(), causing this issue.

Making the napi's weight always non-zero solves this problem.

Triggering this issue requires system-wide admin (setting is not namespaced).(CVE-2025-21806)

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

net: xdp: Disallow attaching device-bound programs in generic mode

Device-bound programs are used to support RX metadata kfuncs. These kfuncs are driver-specific and rely on the driver context to read the metadata. This means they can't work in generic XDP mode. However, there is no check to disallow such programs from being attached in generic mode, in which case the metadata kfuncs will be called in an invalid context, leading to crashes.

Fix this by adding a check to disallow attaching device-bound programs in generic mode.(CVE-2025-21808)

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

driver core: class: Fix wild pointer dereferences in API classdeviter_next()

There are a potential wild pointer dereferences issue regarding APIs classdeviter_(init|next|exit)(), as explained by below typical usage:

// All members of @iter are wild pointers. struct classdeviter iter;

// classdeviterinit(@iter, @class, ...) checks parameter @class for // potential classtosubsys() error, and it returns void type and does // not initialize its output parameter @iter, so caller can not detect // the error and continues to invoke classdeviternext(@iter) even if // @iter still contains wild pointers. classdeviter_init(&iter, ...);

// Dereference these wild pointers in @iter here once suffer the error. while (dev = classdeviter_next(&iter)) { ... };

// Also dereference these wild pointers here. classdeviter_exit(&iter);

Actually, all callers of these APIs have such usage pattern in kernel tree. Fix by: - Initialize output parameter @iter by memset() in classdeviterinit() and give callers prompt by prcrit() for the error. - Check if @iter is valid in classdeviter_next().(CVE-2025-21810)

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

nilfs2: protect access to buffers with no active references

nilfslookupdirtydatabuffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages.

For data cache, nilfsclearfoliodirty() may be called asynchronously when the file system degenerates to read only, so nilfslookupdirtydatabuffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by trytofreebuffers().

Eliminate this race issue by adjusting the lock section in this function.(CVE-2025-21811)

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

ax25: rcu protect dev->ax25_ptr

syzbot found a lockdep issue [1].

We should remove ax25 RTNL dependency in ax25_setsockopt()

This should also fix a variety of possible UAF in ax25.

[1]

WARNING: possible circular locking dependency detected

6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted

syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnlmutex){+.+.}-{4:4}, at: ax25setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680

but task is already holding lock: ffff8880617ac258 (sklock-AFAX25){+.+.}-{0:0}, at: locksock include/net/sock.h:1618 [inline] ffff8880617ac258 (sklock-AFAX25){+.+.}-{0:0}, at: ax25setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (sklock-AFAX25){+.+.}-{0:0}: lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 locksocknested+0x48/0x100 net/core/sock.c:3642 locksock include/net/sock.h:1618 [inline] ax25killbydevice net/ax25/afax25.c:101 [inline] ax25deviceevent+0x24d/0x580 net/ax25/afax25.c:146 notifiercallchain+0x1a5/0x3f0 kernel/notifier.c:85 _devnotifyflags+0x207/0x400 devchangeflags+0xf0/0x1a0 net/core/dev.c:9026 devifsioc+0x7c8/0xe70 net/core/devioctl.c:563 devioctl+0x719/0x1340 net/core/devioctl.c:820 sockdoioctl+0x240/0x460 net/socket.c:1234 sockioctl+0x626/0x8e0 net/socket.c:1339 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:906 [inline] _sesysioctl+0xf5/0x170 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

-> #0 (rtnlmutex){+.+.}-{4:4}: checkprevadd kernel/locking/lockdep.c:3161 [inline] checkprevsadd kernel/locking/lockdep.c:3280 [inline] validatechain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 _lockacquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 _mutexlockcommon kernel/locking/mutex.c:585 [inline] _mutexlock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25setsockopt+0xa55/0xe90 net/ax25/afax25.c:680 dosocksetsockopt+0x3af/0x720 net/socket.c:2324 _syssetsockopt net/socket.c:2349 [inline] _dosyssetsockopt net/socket.c:2355 [inline] _sesyssetsockopt net/socket.c:2352 [inline] _x64syssetsockopt+0x1ee/0x280 net/socket.c:2352 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

other info that might help us debug this:

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(sklock-AFAX25); lock(rtnlmutex); lock(sklock-AFAX25); lock(rtnlmutex);

* DEADLOCK *

1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sklock-AFAX25){+.+.}-{0:0}, at: locksock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sklock-AFAX25){+.+.}-{0:0}, at: ax25setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574

stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printcircularbug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 checknoncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 checkprevadd kernel/locking/lockdep.c:3161 [inline] checkprevs_add kernel/lockin ---truncated---(CVE-2025-21812)

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

wifi: mac80211: don't flush non-uploaded STAs

If STA state is pre-moved to AUTHORIZED (such as in IBSS scenarios) and insertion fails, the station is freed. In this case, the driver never knew about the station, so trying to flush it is unexpected and may crash.

Check if the sta was uploaded to the driver before and fix this.(CVE-2025-21828)

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

bpf: avoid holding freeze_mutex during mmap operation

We use map->freezemutex to prevent races between mapfreeze() and memory mapping BPF map contents with writable permissions. The way we naively do this means we'll hold freeze_mutex for entire duration of all the mm and VMA manipulations, which is completely unnecessary. This can potentially also lead to deadlocks, as reported by syzbot in [0].

So, instead, hold freeze_mutex only during writeability checks, bump (proactively) "write active" count for the map, unlock the mutex and proceed with mmap logic. And only if something went wrong during mmap logic, then undo that "write active" counter increment.

[0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/(CVE-2025-21853)