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:

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:

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:

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:

Input: iforce - bound the device-reported force-feedback effect index

iforceprocesspacket() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array:

i = data[1] & 0x7f; if (data[1] & 0x80) { if (!testandsetbit(FFCOREISPLAYED, iforce->coreeffects[i].flags)) ... } else if (testandclearbit(FFCOREISPLAYED, iforce->coreeffects[i].flags)) { ... }

The index is masked only with 0x7f, so it ranges 0..127, but coreeffects[] holds only IFORCEEFFECTSMAX (32) entries. For an index of 32..127 the testandsetbit()/testandclearbit() is an out-of-bounds single-bit read-modify-write past the array. coreeffects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforceserio / iforceusb object.

data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object.

Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCEEFFECTSMAX rather than dev->ff->maxeffects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate "effect started/stopped" status always carries an index below IFORCEEFFECTSMAX, so well-formed devices are unaffected; the neighbouring markcoreasready() loop is already bounded and is left untouched.

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

Bluetooth: bnep: Fix UAF read of dev->name

bnepaddconnection() needs to keep holding the bnepsessionsem while reading dev->name (just like bnepgetconnlist() does); otherwise the bnepsession() thread can concurrently free the netdevice, which can for example be triggered by a concurrent bnepdelconnection().

(This UAF is fairly uninteresting from a security perspective; calling bnepaddconnection() requires passing a capable(CAPNETADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.)

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

ipv4: raw: reject IPHDRINCL packets with ihl < 5

rawsendhdrinc() validates that the caller-supplied IPv4 header fits within the message length:

iphlen = iph->ihl 4; err = -EINVAL; if (iphlen > length) goto errorfree;

if (iphlen >= sizeof(iph)) { / fix up saddr, totlen, id, csum, transportheader / }

It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to iplocalout() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ahoutput() in particular subtracts sizeof(struct iphdr) from topiph->ihl 4 and passes the (signed-int-negative, then cast to sizet) result to memcpy(), producing an OOB access of length close to SIZEMAX and a host kernel panic.

An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path.

Reject "iphlen < sizeof(iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to.

Once this lands, the "if (iphlen >= sizeof(iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it.

Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl.

Reachability: the malformed packet source is any caller with CAPNETRAW, including an unprivileged process in a user+net namespace on a kernel with CONFIGUSERNS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAPNETADMIN can install that state and policy in its netns. Loopback bypasses xfrmoutput, so the trigger uses a real netdev.

Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpyorig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NETADMIN on a stock distro kernel.

hdlcppp: sync per-proto timers before freeing hdlc state

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

udf: reject descriptors with oversized CRC length

udfreadtagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable.

Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block.

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

Bluetooth: RFCOMM: hold listener socket in rfcommconnectind()

rfcommgetsockbychannel() scans rfcommsklist under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcommconnectind() then locks the listener, queues a child socket on it, and may notify it after unlocking it.

The buggy scenario involves two paths, with each column showing the order within that path:

rfcommconnectind(): listener close: 1. Find parent in 1. close() enters rfcommgetsockbychannel() rfcommsockrelease(). 2. Drop rfcommsklist.lock 2. rfcommsockshutdown() without pinning parent. closes the listener. 3. Call locksock(parent) and 3. rfcommsockkill() btacceptenqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call skstatechange().

If close wins the race, parent can be freed before rfcommconnectind() reaches locksock(), btacceptenqueue(), or the deferred-setup callback.

Take a reference on the listener before leaving rfcommsklist.lock. After locksock() succeeds, recheck that it is still in BTLISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use.

KASAN reported a slab-use-after-free in locksocknested() from rfcommconnectind(), with the freeing stack going through rfcommsockkill() and rfcommsockrelease().

Bluetooth: RFCOMM: validate skb length in MCC handlers

Bluetooth: bnep: reject short frames before parsing

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:

Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig

net/bluetooth/l2capcore.c:l2capsigchannel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAPECHOREQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHOREQ commands made the target transmit 168 ECHORSP frames over about 220 ms.

Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHORSP frames from one 681-byte fixed-channel signaling packet containing packed ECHOREQ commands.

Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAPCOMMANDREJECTRSP carrying L2CAPREJMTUEXCEEDED before any command is dispatched.

The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read.

The unrestricted BR/EDR signaling parser and ECHOREQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.

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:

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

buildi2cfwhdr() allocates a fixed-size buffer of (161024 - 512) + sizeof(struct tii2cfirmwarerec) bytes, then copies le16tocpu(imgheader->Length) bytes into it without validating that Length fits within the available space after the firmware record header.

imgheader->Length is a le16 from the firmware file and can be up to 65535. checkfwsanity() validates the total firmware size but not imgheader->Length specifically.

Fix by rejecting images where imgheader->Length exceeds the available destination space.

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

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

Bluetooth: serialize acceptq access

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

netfilter: ip6thbh: reject oversized option lists

struct ip6topts stores at most IP6TOPTSOPTSNR option descriptors, but hbhmt6check() does not reject larger optsnr values supplied from userspace.

Validate optsnr in the rule setup path so only match data that fits the fixed-size opts array can be installed. This follows the existing xtables pattern of rejecting invalid user-provided counts in checkentry() and keeps the packet matching path unchanged.

struct ip6topts has a fixed opts[IP6TOPTSOPTSNR] array, where IP6TOPTSOPTSNR is 16, then off-by-one array access is possible:

[ 137.924693][ T8692] UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6thbh.c:110:29 [ 137.926167][ T8692] index 16 is out of range for type 'u16 [16]'

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

dm: fix a buffer overflow in ioctl processing

Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrievestatus:

1. The code in retrievestatus checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = alignptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer

Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = alignptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally

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

ipmi: Add limits to event and receive message requests

The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time.

In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck.

This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data.

This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.

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

ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger

Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race. And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing.

Fix it by covering runtime.oss.trigger bit fled also with the existing paramslock mutex in both sndpcmossgettrigger() and sndpcmosspoll().

ibmasm: fix heap over-read in ibmasmsendi2omessage()

ibmasm: fix OOB reads in commandfilewrite due to missing size checks

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

slip: bound decode() reads against the compressed packet length

slhcuncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code.

A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets.

Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.

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

jfs: nlink overflow in jfsrename

If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then dropnlink issues a warning.

After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions.

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

atm: fore200e: fix use-after-free in tasklets during device removal

When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the txtasklet or rxtasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200etxtasklet() or fore200erxtasklet().

One of the race conditions can occur as follows:

CPU 0 (cleanup) | CPU 1 (tasklet) fore200epcaremoveone() | fore200einterrupt() fore200eshutdown() | taskletschedule() kfree(fore200e) | fore200etxtasklet() | fore200e-> // UAF

Fix this by ensuring txtasklet or rxtasklet is properly canceled before the fore200e is released. Add taskletkill() in fore200eshutdown() to synchronize with any pending or running tasklets. Moreover, since fore200ereset() could prevent further interrupts or data transfers, the taskletkill() should be placed after fore200ereset() to prevent the tasklet from being rescheduled in fore200einterrupt(). Finally, it only needs to do taskletkill() when the fore200e state is greater than or equal to FORE200ESTATEIRQ, since tasklets are uninitialized in earlier states. In a word, the taskletkill() should be placed in the FORE200ESTATEIRQ branch within the switch...case structure.

This bug was identified through static analysis.

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

netfilter: xttcpmss: check remaining length before reading optlen

Quoting reporter: In net/netfilter/xttcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length.

If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer opt or the following payload).