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

USB: serial: ioti: fix heap overflow in getmanufinfo()

getmanufinfo() reads le16tocpu(romdesc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmallocobj(), which is sizeof(struct edgetimanufdescriptor) = 10 bytes.

The Size field comes from the device and is only validated (in checki2cimage()) to make sure the descriptor fits within TIMAXI2CSIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver.

validcsum() is called after readrom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access.

Fix by rejecting descriptors with unexpected length before calling readrom().

[ johan: amend commit message; also check for short descriptors ]

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

posix-cpu-timers: Fix pid refcount leak in docpunanosleep() error path

In docpunanosleep(), posixcputimercreate() takes a pid reference via getpid() and stores it in timer.it.cpu.pid. If the subsequent posixcputimerset() call fails, the function returns immediately without calling posixcputimerdel() to release the pid reference, causing a leak.

Fix it by calling posixcputimerdel() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.

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

netfilter: ebtables: zero chainstack array

sashiko reports: looking at ebtables table translation, could a sparse cpupossiblemask lead to an uninitialized pointer free?

If cpupossiblemask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmallocnode() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1].

Not a real-world bug, such allocation isn't expected to fail in the first place.

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

isofs: bound Rock Ridge symlink components to the SL record

getsymlinkchunk() and the SL handling in parserockridgeinodeinternal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and getsymlinkchunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it.

A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; getsymlinkchunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory.

ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAPSYSADMIN - so the record contents are attacker-controlled.

Reject any component that does not fit in the remaining record bytes before using it. In getsymlinkchunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parserockridgeinodeinternal() stop the inode-size walk.

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

netfilter: ebtables: terminate table name before findtablelock()

updatecounters() and compatupdatecounters() forward a user-supplied 32-byte table name to findtablelock() without NUL-terminating it. On a lookup miss, findinlistlock() calls trythenrequestmodule(..., "%s%s", "ebtable", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte.

BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) requestmodule (kernel/module/kmod.c:150) doupdatecounters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) updatecounters (net/bridge/netfilter/ebtables.c:1440) doebtsetctl (net/bridge/netfilter/ebtables.c:2573) nfsetsockopt (net/netfilter/nfsockopt.c:101) ipsetsockopt (net/ipv4/ipsockglue.c:1424) rawsetsockopt (net/ipv4/raw.c:847) syssetsockopt (net/socket.c:2393) ...

compatdoreplace() shares the same unterminated name via compatcopyebtreplacefromuser(); terminate it there too so all findtablelock() callers behave alike. The other callers already terminate the name after the copy.

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

ipv4: restrict IPOPTSSRR and IPOPTLSRR options

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

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

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

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

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

tcp: restrict SOATTACHFILTER to priv users

This patch restricts the use of SOATTACHFILTER (cBPF) on TCP sockets to users with CAPNETADMIN capability.

This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.

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

fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling

A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in sendsigio() and sendsigurg() when a process group receives a signal.

When FASYNC is configured for a process group (PIDTYPEPGID), both functions use readlock(&tasklistlock) to traverse the task list. However, they are frequently called from softirq context: - sendsigio() via inputinjectevent -> killfasync - sendsigurg() via tcpcheckurg -> sksendsigurg (NETRXSOFTIRQ)

The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds readlock(&tasklistlock) in dowait(). 2. CPU 1 (process context) attempts writelock(&tasklistlock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls sendsigurg() and attempts to acquire readlock(&tasklistlock), deadlocking because CPU 1 is waiting.

Since PID hashing and doeachpidtask() traversals are already RCU-protected, the readlock on tasklistlock is no longer strictly required for safe traversal. Fix this by replacing tasklistlock with rcureadlock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets.

Lockdep splat: ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->eventlock --> &fowner->lock --> tasklistlock

Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklistlock); localirqdisable(); lock(&dev->eventlock); lock(&fowner->lock); <Interrupt> lock(&dev->eventlock);

DEADLOCK

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

net: add proper RCU protection to /proc/net/ptype

Yin Fengwei reported an RCU stall in ptypeseqshow() and provided a patch.

Real issue is that ptypeseqnext() and ptypeseqshow() violate RCU rules.

ptypeseqshow() runs under rcureadlock(), and reads pt->dev to get device name without any barrier.

At the same time, concurrent writers can remove a packettype structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.

Define ptypeiterstate to carry a dev pointer along seqnetprivate:

struct ptypeiterstate { struct seqnetprivate p; struct netdevice dev; // added in this patch };

We need to record the device pointer in ptypegetidx() and ptypeseqnext() so that ptypeseqshow() is safe against concurrent pt->dev changes.

We also need to add full RCU protection in ptypeseqnext(). (Missing READONCE() when reading list.next values)

Many thanks to Dong Chenchen for providing a repro.

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

net/x25: Fix potential double free of skb

When allocskb fails in x25queuerxframe it calls kfreeskb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain:

x25queuerxframe returns 1 | v x25state3machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25processrxframe returns queued=0 | v x25backlogrcv at line 452 sees queued=0 and calls kfreeskb(skb) again

This would free the same skb twice. Looking at x25backlogrcv:

net/x25/x25in.c:x25backlogrcv() { ... queued = x25processrxframe(sk, skb); ... if (!queued) kfreeskb(skb); }

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

netfilter: ip6trt: reject oversized addrnr in rtmt6check()

Reject rt match rules whose addrnr exceeds IP6TRTHOPS.

rtmt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value.

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

xfrm: clear trailing padding in buildpolexpire()

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

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

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

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

module: Fix kernel panic when a symbol stshndx is out of bounds

The module loader doesn't check for bounds of the ELF section index in simplifysymbols():

for (i = 1; i < symsec->shsize / sizeof(ElfSym); i++) { const char name = info->strtab + sym[i].stname;

switch (sym[i].stshndx) { case SHNCOMMON:

[...]

default: / Divert to percpu allocation if a percpu var. / if (sym[i].stshndx == info->index.pcpu) secbase = (unsigned long)modpercpu(mod); else / HERE --> / secbase = info->sechdrs[sym[i].stshndx].shaddr; sym[i].stvalue += secbase; break; } }

A symbol with an out-of-bounds stshndx value, for example 0xffff (known as SHNXINDEX or SHNHIRESERVE), may cause a kernel panic:

BUG: unable to handle page fault for address: ... RIP: 0010:simplifysymbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception

This can happen when module ELF is legitimately using SHNXINDEX or when it is corrupted.

Add a bounds check in simplifysymbols() to validate that stshndx is within the valid range before using it.

This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1].

[1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/

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

net/sched: schhfsc: fix divide-by-zero in rtscmin()

m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtscmin() stores the difference of two such u64 values in a u32 variable dsm and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path:

Oops: divide error: 0000 RIP: 0010:rtscmin (net/sched/schhfsc.c:601) Call Trace: inited (net/sched/schhfsc.c:629) hfscenqueue (net/sched/schhfsc.c:1569) [...]

Widen dsm to u64 and replace dodiv() with div64u64() so the full difference is preserved.

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

net/x25: Fix overflow when accumulating packets

Add a check to ensure that x25sock.fraglen does not overflow.

The fraglen also needs to be resetted when purging fragmentqueue in x25clearqueues().

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

nfsd: fix heap overflow in NFSv4.0 LOCK replay cache

The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rpibuf[NFSD4REPLAYISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4OPAQUELIMIT).

When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4encodeoperation() copies the full encoded response into the undersized replay buffer via readbytesfromxdrbuf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory.

This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial.

We could fix this by increasing NFSD4REPLAYISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large.

Instead, fix this by checking the encoded response length against NFSD4REPLAYISIZE before copying into the replay buffer. If the response is too large, set rpbuflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.

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

mtd: Avoid boot crash in RedBoot partition table parser

Given CONFIGFORTIFYSOURCE=y and a recent compiler, commit 439a1bcac648 ("fortify: Use builtindynamicobjectsize() when available") produces the warning below and an oops.

Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000 ------------[ cut here ]------------ WARNING: lib/stringhelpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1 memcmp: detected buffer overflow: 15 byte read of buffer size 14 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE

As Kees said, "'names' is pointing to the final 'namelen' many bytes of the allocation ... 'namelen' could be basically any length at all. This fortify warning looks legit to me -- this code used to be reading beyond the end of the allocation."

Since the size of the dynamic allocation is calculated with strlen() we can use strcmp() instead of memcmp() and remain within bounds.

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

net: usb: pegasus: validate USB endpoints

The pegasus driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.

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

net: rose: include node references in roseneigh refcount

Current implementation maintains two separate reference counting mechanisms: the 'count' field in struct roseneigh tracks references from rosenode structures, while the 'use' field (now refcountt) tracks references from rosesock.

This patch merges these two reference counting systems using 'use' field for proper reference management. Specifically, this patch adds incrementing and decrementing of roseneigh->use when roseneigh->count is incremented or decremented.

This patch also modifies rosertfree(), rosertdevicedown() and roseclearroute() to properly release references to roseneigh objects before freeing a rosenode through roseremovenode().

These changes ensure roseneigh structures are properly freed only when all references, including those from rosenode structures, are released. As a result, this resolves a slab-use-after-free issue reported by Syzbot.

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

net: rose: convert 'use' field to refcountt

The 'use' field in struct roseneigh is used as a reference counter but lacks atomicity. This can lead to race conditions where a roseneigh structure is freed while still being referenced by other code paths.

For example, when roseneigh->use becomes zero during an ioctl operation via rosertioctl(), the structure may be removed while its timer is still active, potentially causing use-after-free issues.

This patch changes the type of 'use' from unsigned short to refcountt and updates all code paths to use roseneighhold() and roseneighput() which operate reference counts atomically.

fs/buffer: fix use-after-free when call bhread() helper

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

llc: do not use skbget() before devqueuexmit()

syzbot is able to crash hosts [1], using llc and devices not supporting IFFTXSKBSHARING.

In this case, e1000 driver calls ethskbpad(), while the skb is shared.

Simply replace skbget() by skbclone() in net/llc/llcsac.c

Note that e1000 driver might have an issue with pktgen, because it does not clear IFFTXSKBSHARING, this is an orthogonal change.

We need to audit other skbget() uses in net/llc.

[1]

kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskbexpandhead+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> skbpad+0x18a/0x610 net/core/skbuff.c:2466 skbputpadto include/linux/skbuff.h:3843 [inline] skbputpadto include/linux/skbuff.h:3862 [inline] ethskbpad include/linux/etherdevice.h:656 [inline] e1000xmitframe+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000main.c:3128 netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3806 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3822 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 devxmitskb net/core/dev.c:4045 [inline] devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4621 devqueuexmit include/linux/netdevice.h:3313 [inline] llcsapactionsendtestc+0x268/0x320 net/llc/llcsac.c:144 llcexecsaptransactions net/llc/llcsap.c:153 [inline] llcsapnextstate net/llc/llcsap.c:182 [inline] llcsapstateprocess+0x239/0x510 net/llc/llcsap.c:209 llcuisendmsg+0xd0d/0x14e0 net/llc/afllc.c:993 socksendmsgnosec net/socket.c:718 [inline]

acct: perform last write from workqueue

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

net: rose: fix timer races against user threads

Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread.

Add a check and rearm the timers if needed.

BUG: KASAN: slab-use-after-free in rosetimerexpiry+0x31d/0x360 net/rose/rosetimer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0

CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 rosetimerexpiry+0x31d/0x360 net/rose/rosetimer.c:174 calltimerfn+0x187/0x650 kernel/time/timer.c:1793 expiretimers kernel/time/timer.c:1844 [inline] runtimers kernel/time/timer.c:2418 [inline] runtimerbase+0x66a/0x8e0 kernel/time/timer.c:2430 runtimerbase kernel/time/timer.c:2439 [inline] runtimersoftirq+0xb7/0x170 kernel/time/timer.c:2449 handlesoftirqs+0x2d4/0x9b0 kernel/softirq.c:561 dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] irqexitrcu+0xf7/0x220 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimerinterrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ>

ax25: fix use-after-free bugs caused by ax25dsdeltimer

dm log: fix out-of-bounds write due to regioncount overflow

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

USB: serial: digiacceleport: fix write buffer corruption

The digiwriteinbcommand() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout.

To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIALJIFFIES).

Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended.

This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.

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

USB: serial: digiacceleport: fix hard lockup on disconnect

If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled.

Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), settermios() or close() races with a physical disconnect.

This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.

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

USB: serial: digiacceleport: fix broken rx after throttle

If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound).

Clear the throttle flags and submit the urb if needed when opening the port.

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