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:

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:

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:

MIPS: DEC: Prevent initial console buffer from landing in XKPHYS

In 64-bit configurations calling the initial console output handler from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment and consequently so has been the buffer allocated there that is used as the argument corresponding to the %s' output conversion specifier for the firmware's printf() entry point.

This 64-bit address will then be truncated by 32-bit firmware, resulting in an attempt to access the wrong memory location, which in turn will cause all kinds of unpredictable behaviour, such as a kernel crash:

Console: colour dummy device 160x64 Calibrating delay loop... 49.36 BogoMIPS (lpj=192512) pidmax: default: 32768 minimum: 301 CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800 Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121 $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0 $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073 $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473 $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000 $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240 $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b $24 : ffffffffffffffbf 000000000203bd00 $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800 Hi : 0000000000000000 Lo : 0000000000000aa8 epc : ffffffffbfc08364 0xffffffffbfc08364 ra : ffffffffbfc08800 0xffffffffbfc08800 Status: 140120e2 KX SX UX KERNEL EXL Cause : 00000008 (ExcCode 02) BadVA : 000000000203bd00 PrId : 00000430 (R4000SC) Modules linked in: Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=0000000000000000) Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38 0000000000000000 000000000203bd00 0000000000000000 0000000000000000 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000 ... Call Trace:

Code: a082ffff 03e00008 00601021 <80820000> 00001821 10400005 24840001 80820000 24630001

---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt

KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8) >>

In this case the pointer in $4 was truncated from 0x980000000203bd00 to 0x000000000203bd00.

This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started.

Fix the issue by making the buffer static and initdata, and therefore placed in the CKSEG0 32-bit compatibility segment, observing that the console output handler is called with the console lock held, implying no need for this code to be reentrant. Add an assertion to verify the buffer actually has been placed in a compatibility segment.

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

fbdev: Fix fbnewmodelist to prevent null-ptr-deref in fbvideomodetovar

info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. vartodisplay() relies on this and treats a failed fbmatchmode() as "This should not happen". fbsetvar() keeps it true by adding the mode to the list on every change, and doregisterframebuffer() does the same at registration.

storemodes() replaces the modelist from userspace. fbnewmodelist() validates the new modes but does not check that info->var still has a match. It relies on fbconnewmodelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list.

A later console takeover runs vartodisplay(), where fbmatchmode() returns NULL and leaves fbdisplay[i].mode NULL. fbconswitch() passes it to displaytovar(), and fbvideomodetovar() dereferences the NULL mode.

Keep the current mode in the list in fbnewmodelist(), the same way fbsetvar() does.

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

hfsplus: fix uninit-value by validating catalog record size

Syzbot reported a KMSAN uninit-value issue in hfsplusstrcasecmp(). The root cause is that hfsbrecread() doesn't validate that the on-disk record size matches the expected size for the record type being read.

When mounting a corrupted filesystem, hfsbrecread() may read less data than expected. For example, when reading a catalog thread record, the debug output showed:

HFSPLUSBRECREAD: reclen=520, fd->entrylength=26 HFSPLUSBRECREAD: WARNING - entrylength (26) < reclen (520) - PARTIAL READ!

hfsbrecread() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized.

This uninitialized data in tmp.thread.nodeName then gets copied by hfspluscatbuildkeyuni() and used by hfsplusstrcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in casefold().

Fix by introducing hfsplusbrecreadcat() wrapper that: 1. Calls hfsbrecread() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected

For thread records, check against HFSPLUSMINTHREADSZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure.

Also initialize the tmp variable in hfsplusfindcat() as defensive programming to ensure no uninitialized data even if validation is bypassed.

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

usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl

Just like in a previous problem in this driver, usblpctrlmsg() will collapse the usbcontrolmsg() return value to 0/-errno, discarding the actual number of bytes transferred.

Ideally that short command should be detected and error out, but many printers are known to send "incorrect" responses back so we can't just do that.

statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl.

usblpreadstatus() requests 1 byte. If a malicious printer responds with zero bytes, statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copytouser()s directly to the ioctl caller.

Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no "leak" of information happening.

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

8021q: delete cleared egress QoS mappings

vlandevsetegresspriority() currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities therefore accumulate mapping nodes until device teardown and leak memory.

Delete mappings when vlanprio is cleared instead of keeping tombstones. Now that the egress mapping lists are RCU protected, the node can be unlinked safely and freed after a grace period.

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

usb: usblp: fix heap leak in IEEE 1284 device ID via short response

usblpctrlmsg() collapses the usbcontrolmsg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GETDEVICEID control transfer short and the driver has no way to know.

usblpcachedeviceidstring() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves deviceidstring[2..1022] holding stale kmalloc heap.

That stale data is then exposed: - via the ieee1284id sysfs attribute (sprintf("%s", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNRGETDEVICEID ioctl, which copytouser()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device.

Fix this up by just zapping the buffer with zeros before each request sent to the device.

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

ipmi: Check event message buffer response for bad data

The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events.

There are apparently some new BMCs that make this error, so we need to compensate.

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

ipmi:si: Return state to normal if message allocation fails

There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.

dm mirror: fix integer overflow in createdirtylog()

ext2: reject inodes with zero inlink and valid mode in ext2iget()

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

net: usb: catc: enable basic endpoint checking

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

- usbsndbulkpipe(usbdev, 1) and usbrcvbulkpipe(usbdev, 1) for TX/RX - usbrcvintpipe(usbdev, 2) for interrupt status

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

Add a catcusbep enum for endpoint numbers, replacing magic constants throughout. Add usbcheckbulkendpoints() and usbcheckintendpoints() calls after usbsetinterface() to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time.

Similar to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") which fixed the issue in rtl8150.

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:

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:

ACPI: processor: Fix NULL-pointer dereference in acpiprocessorerratapiix4()

In acpiprocessorerratapiix4(), the pointer dev is first assigned an IDE device and then reassigned an ISA device:

dev = pcigetsubsys(..., PCIDEVICEIDINTEL82371AB, ...); dev = pcigetsubsys(..., PCIDEVICEIDINTEL82371AB0, ...);

If the first lookup succeeds but the second fails, dev becomes NULL. This leads to a potential null-pointer dereference when devdbg() is called:

if (errata.piix4.bmisx) devdbg(&dev->dev, ...);

To prevent this, use two temporary pointers and retrieve each device independently, avoiding overwriting dev with a possible NULL value.

[ rjw: Subject adjustment, added an empty code line ]

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:

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.

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:

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:

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:

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

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

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:

sunrpc: fix cacherequest leak in cacherelease

When a reader's file descriptor is closed while in the middle of reading a cacherequest (rp->offset != 0), cacherelease() decrements the request's readers count but never checks whether it should free the request.

In cacheread(), when readers drops to 0 and CACHEPENDING is clear, the cacherequest is removed from the queue and freed along with its buffer and cachehead reference. cacherelease() lacks this cleanup.

The only other path that frees requests with readers == 0 is cachedequeue(), but it runs only when CACHEPENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cachedequeue() will have skipped the request, and no subsequent call will clean it up.

Add the same cleanup logic from cacheread() to cacherelease(): after decrementing readers, check if it reached 0 with CACHEPENDING clear, and if so, dequeue and free the cacherequest.

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:

serial: core: fix infinite loop in handletx() for PORTUNKNOWN

uartwriteroom() and uartwrite() behave inconsistently when xmitbuf is NULL (which happens for PORTUNKNOWN ports that were never properly initialized):

- uartwriteroom() returns kfifoavail() which can be > 0 - uartwrite() checks xmitbuf and returns 0 if NULL

This inconsistency causes an infinite loop in drivers that rely on ttywriteroom() to determine if they can write:

while (ttywriteroom(tty) > 0) { written = tty->ops->write(...); // written is always 0, loop never exits }

For example, caifserial's handletx() enters an infinite loop when used with PORTUNKNOWN serial ports, causing system hangs.

Fix by making uartwriteroom() also check xmitbuf and return 0 if it's NULL, consistent with uartwrite().

Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13

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

net/rose: fix NULL pointer dereference in rosetransmitlink on reconnect

syzkaller reported a bug [1], and the reproducer is available at [2].

ROSE sockets use four sk->skstate values: TCPCLOSE, TCPLISTEN, TCPSYNSENT, and TCPESTABLISHED. roseconnect() already rejects calls for TCPESTABLISHED (-EISCONN) and TCPCLOSE with SSCONNECTING (-ECONNREFUSED), but lacks a check for TCPSYNSENT.

When roseconnect() is called a second time while the first connection attempt is still in progress (TCPSYNSENT), it overwrites rose->neighbour via rosegetneigh(). If that returns NULL, the socket is left with rose->state == ROSESTATE1 but rose->neighbour == NULL. When the socket is subsequently closed, roserelease() sees ROSESTATE1 and calls rosewriteinternal() -> rosetransmitlink(skb, NULL), causing a NULL pointer dereference.

Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCPSYNSENT to complete the state validation in roseconnect().

[1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516

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

net: usb: kaweth: validate USB endpoints

The kaweth 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.