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

Input: lkkbd - disable pending work before freeing device

lkkbdinterrupt() schedules lk->tq via schedulework(), and the work handler lkkbdreinit() dereferences the lkkbd structure and its serio/inputdev fields.

lkkbddisconnect() and error paths in lkkbdconnect() free the lkkbd structure without preventing the reinit work from being queued again until serioclose() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.

Use disableworksync() instead of cancelworksync() to ensure the reinit work cannot be re-queued, and call it both in lkkbddisconnect() and in lkkbdconnect() error paths after serioopen().

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

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.

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:

fbdev: fix use-after-free in storemodes()

storemodes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fbdestroymodelist(). Two fields still point into that freed list.

One pointer is fbdisplay[i].mode, the mode a console is using. fbconnewmodelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fbmap[i] to -1 but leaves fbdisplay[i].mode set. An FBIOPUTVSCREENINFO ioctl with FBACTIVATEINVMODE later reaches fbconmodedeleted(). That function reads the stale fbdisplay[i].mode through fbmodeisequal(). The read is a use-after-free.

The other pointer is fbinfo->mode, the current mode. It is set through the mode sysfs attribute. storemodes() does not update fbinfo->mode, so it is left pointing into the freed list. showmode(), the attribute's read handler, dereferences the stale fbinfo->mode through modestring(). The read is a use-after-free.

Clear both pointers before freeing the list. Commit a1f305893074 ("fbcon: Set fbdisplay[i]->mode to NULL when the mode is released") added the helper fbcondeletemodelist(). It clears every fbdisplay[i].mode that points into a given list. So far it is called only from the unregister path. Call it from storemodes() too, and set fbinfo->mode to NULL.

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

usb: image: mdc800: kill download URB on timeout

mdc800deviceread() submits downloadurb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active.

A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usbsubmiturb():

"URB submitted while active"

Check the return value of waiteventtimeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted.

Similar to - commit 372c93131998 ("USB: yurex: fix control-URB timeout handling") - commit b98d5000c505 ("media: rc: iguanair: handle timeouts")

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

hfsplus: pretend special inodes as regular files

Since commit af153bb63a33 ("vfs: catch invalid modes in mayopen()") requires any inode be one of SIFDIR/SIFLNK/SIFREG/SIFCHR/SIFBLK/ SIFIFO/SIFSOCK type, use SIFREG for special inodes.

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

xfs: fix freemap adjustments when adding xattrs to leaf blocks

xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs:

ASSERT(ichdr->firstused >= ichdr->count sizeof(xfsattrleafentryt) + xfsattr3leafhdrsize(leaf));

Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes.

At the start of xfsattr3leafaddwork, the freemap looks like this:

i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520

where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388!

By the end of the function, the freemap is in worse shape:

i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440

Important note: 388 is not aligned with the entries array element size of 8 bytes.

Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down.

How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with:

376 bytes in use by the entries array freemap[0] has [base = 376, size = 8] freemap[1] has [base = 388, size = 1500] the space between 376 and 388 is free, but the freemap stopped tracking that some time ago

If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space.

The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0.

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

net: usb: pegasus: enable basic endpoint checking

pegasusprobe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors:

- usbrcvbulkpipe(dev, 1) for RX data - usbsndbulkpipe(dev, 2) for TX data - usbrcvintpipe(dev, 3) for status interrupts

A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes.

Add a pegasususbep enum for endpoint numbers, replacing magic constants throughout. Add usbcheckbulkendpoints() and usbcheckintendpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion.

Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")

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

ALSA: mixer: oss: Add card disconnect checkpoints

ALSA OSS mixer layer calls the kcontrol ops rather individually, and pending calls might be not always caught at disconnecting the device.

For avoiding the potential UAF scenarios, add sanity checks of the card disconnection at each entry point of OSS mixer accesses. The rwsem is taken just before that check, hence the rest context should be covered by that properly.

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).

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

net: usb: kaweth: remove TX queue manipulation in kawethsetrxmode

kawethsetrxmode(), the ndosetrxmode callback, calls netifstopqueue() and netifwakequeue(). These are TX queue flow control functions unrelated to RX multicast configuration.

The premature netifwakequeue() can re-enable TX while txurb is still in-flight, leading to a double usbsubmiturb() on the same URB:

kawethstartxmit() { netifstopqueue(); usbsubmiturb(kaweth->txurb); }

kawethsetrxmode() { netifstopqueue(); netifwakequeue(); // wakes TX queue before URB is done }

kawethstartxmit() { netifstopqueue(); usbsubmiturb(kaweth->txurb); // URB submitted while active }

This triggers the WARN in usbsubmiturb():

"URB submitted while active"

This is a similar class of bug fixed in rtl8150 by

- commit 958baf5eaee3 ("net: usb: Remove disruptive netifwakequeue in rtl8150setmulticast").

Also kawethsetrxmode() is already functionally broken, the real setrxmode action is performed by kawethasyncsetrxmode(), which in turn is not a no-op only at ndoopen() time.

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

xfs: close crash window in attr dabtree inactivation

When inactivating an inode with node-format extended attributes, xfsattr3nodeinactive() invalidates all child leaf/node blocks via xfstransbinval(), but intentionally does not remove the corresponding entries from their parent node blocks. The implicit assumption is that xfsattrinactive() will truncate the entire attr fork to zero extents afterwards, so log recovery will never reach the root node and follow those stale pointers.

However, if a log shutdown occurs after the leaf/node block cancellations commit but before the attr bmap truncation commits, this assumption breaks. Recovery replays the attr bmap intact (the inode still has attr fork extents), but suppresses replay of all cancelled leaf/node blocks, maybe leaving them as stale data on disk. On the next mount, xlogrecoverprocessiunlinks() retries inactivation and attempts to read the root node via the attr bmap. If the root node was not replayed, reading the unreplayed root block triggers a metadata verification failure immediately; if it was replayed, following its child pointers to unreplayed child blocks triggers the same failure:

XFS (pmem0): Metadata corruption detected at xfsda3nodereadverify+0x53/0x220, xfsda3node block 0x78 XFS (pmem0): Unmount and run xfsrepair XFS (pmem0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (pmem0): metadata I/O error in "xfsdareadbuf+0x104/0x190" at daddr 0x78 len 8 error 117

Fix this in two places:

In xfsattr3nodeinactive(), after calling xfstransbinval() on a child block, immediately remove the entry that references it from the parent node in the same transaction. This eliminates the window where the parent holds a pointer to a cancelled block. Once all children are removed, the now-empty root node is converted to a leaf block within the same transaction. This node-to-leaf conversion is necessary for crash safety. If the system shutdown after the empty node is written to the log but before the second-phase bmap truncation commits, log recovery will attempt to verify the root block on disk. xfsda3nodeverify() does not permit a node block with count == 0; such a block will fail verification and trigger a metadata corruption shutdown. on the other hand, leaf blocks are allowed to have this transient state.

In xfsattrinactive(), split the attr fork truncation into two explicit phases. First, truncate all extents beyond the root block (the child extents whose parent references have already been removed above). Second, invalidate the root block and truncate the attr bmap to zero in a single transaction. The two operations in the second phase must be atomic: as long as the attr bmap has any non-zero length, recovery can follow it to the root block, so the root block invalidation must commit together with the bmap-to-zero truncation.

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

atm: lec: fix use-after-free in sockdefreadable()

A race condition exists between lecatmclose() setting priv->lecd to NULL and concurrent access to priv->lecd in sendtolecd(), lechandlebridge(), and lecatmsend(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sockdefreadable() when accessing the socket's wait queue.

The root cause is that lecatmclose() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown.

Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as rcu in lec.h - Use rcuassignpointer() in lecatmclose() and lecdattach() for safe pointer assignment - Use rcuaccesspointer() for NULL checks that do not dereference the pointer in lecstartxmit(), lecpush(), sendtolecd() and lecdattach() - Use rcureadlock/rcudereference/rcureadunlock in sendtolecd(), lechandlebridge() and lecatmsend() to safely access lecd - Use rcuassignpointer() followed by synchronizercu() in lecatmclose() to ensure all readers have completed before proceeding. This is safe since lecatmclose() is called from vccrelease() which holds locksock(), a sleeping lock. - Remove the manual skreceivequeue drain from lecatmclose() since vccdestroysocket() already drains it after lecatmclose() returns.

v2: Switch from spinlock + sockhold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lecatmclose() drains skreceivequeue since timer and workqueue paths bypass netifstopqueue().

Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with "Connection to localhost closed by remote host", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with "make W=1 net/atm/lec.o" passes cleanly.

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

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

xfs: delete attr leaf freemap entries when empty

Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block.

This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in leafadd that finds free space ignores any freemap entry with zero size.

However, there's another bug in the freemap update code in leafadd, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent leafadd can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later.

For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap.

It looks like this bug has been in the codebase for quite a long time.

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

netfilter: ip6teui64: reject invalid MAC header for all packets

eui64mt6() derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address.

The existing guard only rejects an invalid MAC header when par->fragoff != 0. For packets with par->fragoff == 0, eui64mt6() can still reach ethhdr(skb) even when the MAC header is not valid.

Fix this by removing the par->fragoff != 0 condition so that packets with an invalid MAC header are rejected before accessing ethhdr(skb).

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

USB: core: Limit the length of unkillable synchronous timeouts

The usbcontrolmsg(), usbbulkmsg(), and usbinterruptmsg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device.

To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector.

In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout.

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:

minix: Add required sanity checking to minixchecksuperblock()

The fs/minix implementation of the minix filesystem does not currently support any other value for slogzonesize than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minixblocksneeded() checks for the zmap and imap also to minixchecksuperblock().

This also closes a related syzbot bug report.

fbdev: tdfxfb: avoid divide-by-zero on FBIOPUTVSCREENINFO

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

net: afkey: zero aligned sockaddr tail in PFKEY exports

PFKEY export paths use pfkeysockaddrsize() when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, pfkeysockaddrfill() initializes only the first 28 bytes of struct sockaddrin6, leaving the final 4 aligned bytes uninitialized.

Not every PFKEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain skbput():

- SADBACQUIRE - SADBXNATTNEWMAPPING - SADBXMIGRATE

Fix those paths by clearing only the aligned sockaddr tail after pfkeysockaddrfill().

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/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:

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:

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:

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:

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:

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.