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

Input: elani2c - prevent division by zero and arithmetic underflow

The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for xtraces or ytraces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe.

Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1.

Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETPFWIDTHREDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios.

Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.

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:

tty: serial: pchuart: add check for dmaalloccoherent()

Add a check for dmaalloccoherent() failure to prevent a potential NULL pointer dereference in dmahandlerx(). Properly release DMA channels and the PCI device reference using a goto ladder if the allocation fails.

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

device property: set fwnode->secondary to NULL in fwnodeinit()

If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnodeinit(), its secondary pointer will contain uninitalized memory which likely will be neither NULL nor ISERR() and so may end up being dereferenced (for example: in devtoswnode()). Set fwnode->secondary to NULL on initialization.

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

sysfs: don't remove existing directory on update failure

When sysfsupdategroup() is called for a named group and createfiles() fails (e.g. -ENOMEM), internalcreategroup() calls kernfsremove(kn) on the group directory. In the update path, kn was obtained via kernfsfindandget() and refers to a directory that already existed before this call. Removing it silently destroys a sysfs group that the caller did not create.

Only remove the directory if we created it ourselves. On update failure the directory remains as it is left empty by removefiles() inside createfiles(), but can be repopulated by a retry.

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

phonet/pep: disable BH around forwarded skreceiveskb()

The networking receive path is usually run from softirq context, but protocols that take the socket lock may have packets stored in the backlog and processed later from process context. In that case releasesock() -> releasesock() drops the slock with spinunlockbh() and then calls sk->skbacklogrcv() with bottom halves enabled.

Typical skbacklogrcv handlers process the socket whose backlog is being drained, so the BH state at entry is irrelevant for the slocks they touch. pepdorcv() is different: when the inbound skb targets an existing PEP pipe, it forwards the skb to a different child socket via skreceiveskb(). That helper takes the child slock with bhlocksocknested(), which is just spinlocknested() and assumes BH is already off. The same child slock therefore ends up acquired with BH on (process path) and with BH off (softirq path):

process context softirq context --------------- --------------- releasesock(listener) netifreceiveskb() releasesock() phonetrcv() spinunlockbh() skreceiveskb(listener) [BH now ENABLED] [BH already disabled] skbacklogrcv: skbacklogrcv: pepdorcv() pepdorcv() skreceiveskb(child) skreceiveskb(child) bhlocksocknested(child) bhlocksocknested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W

Lockdep flags this as inconsistent lock state, and it can become a real self-deadlock if a softirq on the same CPU tries to receive to the same child socket while its slock is held in the BH-enabled path:

WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. (slock-AFPHONET/1){+.?.}-{3:3}, at: skreceiveskb+0x1cf/0x900 skreceiveskb net/core/sock.c:563 skreceiveskb include/net/sock.h:2022 [inline] pepdorcv net/phonet/pep.c:675 skbacklogrcv include/net/sock.h:1190 releasesock net/core/sock.c:3216 releasesock net/core/sock.c:3815 pepsockaccept net/phonet/pep.c:879

Wrap the forwarded skreceiveskb() in localbhdisable() / localbhenable() so the child slock is always acquired with BH off. localbhdisable() nests safely on the softirq path.

Discovered via in-house syzkaller fuzzing; the same root cause also on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c. Reproduced under KASAN + LOCKDEP + PROVELOCKING, reproducer: https://pastebin.com/A3t8xzCR

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

wifi: cfg80211: advance loop vars in cfg80211mergeprofile()

cfg80211mergeprofile() reassembles a Multi-BSSID non-transmitted BSS profile that has been split across multiple consecutive MBSSID elements. Its while-loop calls

cfg80211getprofilecontinuation(ie, ielen, mbssidelem, subelem)

but never advances mbssidelem or subelem inside the body. Each iteration therefore searches for a continuation that follows the same fixed pair; the helper returns the same nextmbssid; and the same nextsub bytes are memcpy()'d into mergedie at a growing offset until the buffer fills.

Advance both mbssidelem and subelem to the just-consumed continuation so the next call to cfg80211getprofilecontinuation() searches for a further continuation beyond it (or returns NULL when none exists).

A specially-crafted malicious beacon can take advantage of this bug to cause the kernel to spend an excessive amount of time in cfg80211mergeprofile (up to as much as 2ms per beacon received), which could theoretically be abused in some way.

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

tracing: Do not call map->ops->eltfree() if eltalloc() fails

In paths where tracingmapeltalloc() failed to allocate objects, the map->ops->eltalloc() call was never successful. In this case, map->ops->eltfree() should not be called.

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

spi: qup: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

spi: sprd: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time).

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

ARM: integrator: Fix early initialization

Starting with commit bdb249fce9ad4 ("ARM: integrator: read counter using syscon/regmap"), intcpinitearly calls sysconregmaplookupbycompatible which in turn calls ofsysconregister. This function allocates memory. Since the memory management code has not been initialized at that time, the call always fails. It either returns -ENOMEM or crashes as follows.

Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read [0000000c] pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT Hardware name: ARM Integrator/CP (Device Tree) PC is at kmalloccachenoprof+0xec/0x39c LR is at kmalloccachenoprof+0x34/0x39c ... Call trace: kmalloccachenoprof from ofsysconregister+0x7c/0x310 ofsysconregister from devicenodegetregmap+0xa4/0xb0 devicenodegetregmap from intcpinitearly+0xc/0x40 intcpinitearly from startkernel+0x60/0x688 startkernel from 0x0

The crash is seen due to a dereferenced pointer which is not supposed to be NULL but is NULL if the memory management subsystem has not been initialized. The crash is not seen with all versions of gcc. Some versions such as gcc 9.x apparently do not dereference the pointer, presumably if tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x, and 13.x. Either case, if the crash is not seen, the call to sysconregmaplookupbycompatible returns -ENOMEM, and schedclockregister is never called.

Fix the problem by moving the early initialization code into the standard machine initialization code.

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

wifi: ath11k: fix error path leaks in some WMI WOW calls

Fix two instances where we used to directly return the result of ath11kwmicmdsend(...). Because we did not check the return value, we also did not free the skb in the error path.

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

hwmon: (pmbus/adm1266) widen blackbox-info buffer to I2CSMBUSBLOCKMAX

adm1266nvmemreadblackbox() declares a 5-byte stack buffer and passes it to i2csmbusreadblockdata() to retrieve the 4-byte BLACKBOXINFO response. i2csmbusreadblockdata() does not honour caller buffer sizes -- it memcpy()s data.block[0] bytes from the SMBus transaction (where data.block[0] is the length byte returned by the slave device, up to I2CSMBUSBLOCKMAX = 32):

memcpy(values, &data.block[1], data.block[0]);

If the device returns any block length above 5, the call overflows the caller's 5-byte stack buffer before the post-call

if (ret != 4) return -EIO;

check has a chance to reject the response.

Widen the local buffer to I2CSMBUSBLOCKMAX so the helper has room for any well-formed SMBus block response, matching the convention used by the other i2csmbusreadblockdata() callers in this driver.

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

batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface

Without rtnllock held, a hardif might be retrieved as primary interface of a meshif, but then (while operating on this interface) getting decoupled from the mesh interface. In this case, the meshif still exists but the pointer from the primary hardif to the meshif is set to NULL.

The meshiface must be checked first to be non-NULL before continuing to send an ARP request using meshif.

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

batman-adv: tt: avoid empty VLAN responses

The commit 16116dac2339 ("batman-adv: prevent TT request storms by not sending inconsistent TT TLVLs") added checks to the local (direct) TT response code. But the response can also be done indirectly by another node using the global TT state. To avoid such inconsistency states reported in the original fix, also avoid sending empty VLANs for replies from the global TT state.

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

irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove

The driver allocates domain generic chips using irqallocdomaingenericchips() during probe and sets up chained handlers using irqsetchainedhandleranddata(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed.

The generic chips remain on the global gclist and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash.

The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory.

Fix these issues by:

- Setting IRQDOMAINFLAGDESTROYGC flag in domain->flags, so the core code automatically removes generic chips when irqdomainremove() is called

- Clearing all chained handlers with NULL in pdcintcremove()

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:

media: vidtv: fix NULL pointer dereference in vidtvmuxpushsi

syzbot reported a general protection fault in vidtvpsitspsiwriteinto [1].

vidtvmuxgetpidctx() can return NULL, but vidtvmuxpushsi() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address.

The root cause is that vidtvmuxpidctxinit() does not check the return value of vidtvmuxcreatepidctxonce() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtvmuxpushsi() call then gets NULL from vidtvmuxgetpidctx() and crashes.

Fix both the root cause (add error check in vidtvmuxpidctxinit for PMT PIDs) and add defensive NULL checks in vidtvmuxpushsi for all vidtvmuxgetpidctx() calls.

[1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtvmuxtick RIP: 0010:vidtvpsitspsiwriteinto+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtvpsi.c:197 Call Trace: <TASK> vidtvpsitableheaderwriteinto drivers/media/test-drivers/vidtv/vidtvpsi.c:799 [inline] vidtvpsipmtwriteinto+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtvpsi.c:1231 vidtvmuxpushsi+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtvmux.c:196 vidtvmuxtick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtvmux.c:408

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

signal: clear JOBCTLPENDINGMASK for caller in zapotherthreads()

When a multi-threaded process receives a stop signal (e.g., SIGSTOP), dosignalstop() sets JOBCTLSTOPPENDING and JOBCTLSTOPCONSUME on all threads and sets signal->groupstopcount to the number of threads. If one of the threads concurrently calls execve(), dethread() invokes zapotherthreads() to kill all other threads. zapotherthreads() aborts the pending group stop by resetting signal->groupstopcount to 0 and clears the JOBCTLPENDINGMASK for all other threads. However, it fails to clear the job control flags for the calling thread.

When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTLSTOPPENDING flag, it calls dosignalstop(), which invokes taskparticipategroupstop(). Since JOBCTLSTOPCONSUME is still set, it attempts to decrement the already-zero signal->groupstopcount, triggering a warning:

sig->groupstopcount == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 taskparticipategroupstop+0x215/0x2d0 Call Trace: <TASK> dosignalstop+0x3be/0x5c0 kernel/signal.c:2619 getsignal+0xa8c/0x1330 kernel/signal.c:2884 archdosignalorrestart+0xbc/0x840 arch/x86/kernel/signal.c:337 exittousermodeloop+0x8c/0x4d0 kernel/entry/common.c:98 dosyscall64+0x33e/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Fix this race condition by clearing the JOBCTLPENDINGMASK for the calling thread in zapotherthreads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zapprocess() and completesignal(), which correctly clear these flags for all threads including the current one.

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

slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd

When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards.

One such example can be seen in the following fault, where qcomslimngdssrpdrnotify() schedules work on the NULL ngdupwork.

[ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at queuework+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] queuework+0x5e0/0x790 (P) [ 21.859265] queueworkon+0x6c/0xf0 [ 21.859273] qcomslimngdssrpdrnotify+0x110/0x150 [slimqcomngdctrl] [ 21.859304] qcomslimngdssrnotify+0x24/0x40 [slimqcomngdctrl] [ 21.859318] notifiercallchain+0xa4/0x230 [ 21.859329] srcunotifiercallchain+0x64/0xb8 [ 21.859338] ssrnotifystart+0x40/0x78 [qcomcommon] [ 21.859355] rprocstart+0x130/0x230 [ 21.859367] rprocboot+0x3d4/0x518 ...

Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered.

This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.

agp/amd64: Fix broken error propagation in agpamd64probe()

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

nilfs2: reject zero bdoblocknr in nilfsioctlmarkblocksdirty()

nilfsioctlmarkblocksdirty() uses bdoblocknr to detect dead blocks by comparing it with the current block number bdblocknr. If they differ, the block is considered dead and skipped.

However, bdoblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bdoblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bdblocknr to 0, bypassing the dead block check and calling nilfsbmapmark() on a non-existent block. This causes nilfsbtreedolookup() to return -ENOENT, triggering the WARNON(ret == -ENOENT).

Fix this by rejecting ioctl requests with bdoblocknr set to 0 at the beginning of each iteration.

[ryusuke: slightly modified the commit message and comments for accuracy]

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

tty: hvciucv: fix off-by-one in number of supported devices

MAXHVCIUCVLINES == HVCALLOCTTYADAPTERS == 8. This is the number of entries in: static struct hvciucvprivate hvciucvtable[MAXHVCIUCVLINES];

Sometimes hvciucvtable[] is limited by: (a) if (num > hvciucvdevices) // for error detection or (b) for (i = 0; i < hvciucvdevices; i++) // in 2 places (so these 2 don't agree; second one appears to be correct to me.)

hvciucvdevices can be 0..8. This is a counter. (c) if (hvciucvdevices > MAXHVCIUCVLINES)

If hvciucvdevices == 8, (a) allows the code to access hvciucvtable[8]. Oops.

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

scsi: sg: Resolve soft lockup issue when opening /dev/sgX

The parameter defreservedsize defines the default buffer size reserved for each Sgfd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sgprocwritedressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup:

echo -1 > /sys/module/sg/parameters/defreservedsize exec 4<> /dev/sg0

watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace:

sgbuildreserve+0x5c/0xa0 sgaddsfp+0x168/0x270 sgopen+0x16e/0x340 chrdevopen+0xbe/0x230 dodentryopen+0x175/0x480 vfsopen+0x34/0xf0 doopen+0x265/0x3d0 pathopenat+0x110/0x290 dofilpopen+0xc3/0x170 dosysopenat2+0x71/0xe0 x64sysopenat+0x6d/0xa0 dosyscall64+0x62/0x310 entrySYSCALL64afterhwframe+0x76/0x7e

The fix is to use moduleparamcb to validate and reject invalid values assigned to defreservedsize.

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

mailbox: add sanity check for channel array

Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here.

audit: fix incorrect inheritable capability in CAPSET records

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

netfilter: synproxy: add mutex to guard hook reference counting

As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other.

Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.

6lowpan: fix off-by-one in multicast context address compression

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

net/802/mrp: fix vector attribute parsing in mrppduparsevecattr

In mrppduparsevecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process.

The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state.

Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing.

Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value.

Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.

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

netlabel: validate unlabeled address and mask attribute lengths

netlblunlabeladdrinfoget() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct inaddr or struct in6addr.

NLABINARY policy lengths are maximum lengths by default, so use NLAPOLICYEXACTLEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.