🚨 CVE-2026-53303
In the Linux kernel, the following vulnerability has been resolved:

f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show()

In f2fs_sbi_show(), the extension_list, extension_count and
hot_ext_count are read without holding sbi->sb_lock. If a concurrent
sysfs store modifies the extension list via f2fs_update_extension_list(),
the show path may read inconsistent count and array contents, potentially
leading to out-of-bounds access or displaying stale data.

Fix this by holding sb_lock around the entire extension list read
and format operation.

🎖@cveNotify

🚨 CVE-2026-53304
In the Linux kernel, the following vulnerability has been resolved:

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

The parameter def_reserved_size defines the default buffer size reserved
for each Sg_fd 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 sg_proc_write_dressz 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/def_reserved_size
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:

sg_build_reserve+0x5c/0xa0
sg_add_sfp+0x168/0x270
sg_open+0x16e/0x340
chrdev_open+0xbe/0x230
do_dentry_open+0x175/0x480
vfs_open+0x34/0xf0
do_open+0x265/0x3d0
path_openat+0x110/0x290
do_filp_open+0xc3/0x170
do_sys_openat2+0x71/0xe0
__x64_sys_openat+0x6d/0xa0
do_syscall_64+0x62/0x310
entry_SYSCALL_64_after_hwframe+0x76/0x7e

The fix is to use module_param_cb to validate and reject invalid values
assigned to def_reserved_size.

🎖@cveNotify

🚨 CVE-2026-53305
In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ps883x: Fix Oops at unbind

When trying to unbind a device in order to bind to it vfio-platform as:

echo bc0000.geniqup > /sys/bus/platform/devices/bc0000.geniqup/driver/unbind

I get the following Oops:

[ 436.478639] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
[ 436.487762] Mem abort info:
[ 436.490716] ESR = 0x0000000096000004
[ 436.494595] EC = 0x25: DABT (current EL), IL = 32 bits
[ 436.500071] SET = 0, FnV = 0
[ 436.503250] EA = 0, S1PTW = 0
[ 436.506505] FSC = 0x04: level 0 translation fault
[ 436.511533] Data abort info:
[ 436.514558] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 436.520215] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 436.525436] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 436.530918] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008861a9000
[ 436.537554] [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
[ 436.544548] Internal error: Oops: 0000000096000004 [#1] SMP
[ 436.550374] Modules linked in:
[ 436.553542] CPU: 2 UID: 0 PID: 671 Comm: bash Tainted: G W 7.0.0-rc3-g56fcdd0911a5-dirty #2 PREEMPT
[ 436.564440] Tainted: [W]=WARN
[ 436.567515] Hardware name: LENOVO 91B6CTO1WW/3796, BIOS O6NKT3BA 05/02/2025
[ 436.574675] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 436.581841] pc : ps883x_retimer_remove+0x14/0x94
[ 436.586605] lr : i2c_device_remove+0x28/0x84
[ 436.591017] sp : ffff8000847137c0

That's because the ps883x_retimer_remove() retrieves the driver data
from i2c_get_clientdata() which was never set at probe. So, add
i2c_set_clientdata() at the end of the probe.

🎖@cveNotify

🚨 CVE-2026-53306
In the Linux kernel, the following vulnerability has been resolved:

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

MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8.
This is the number of entries in:
static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES];

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

hvc_iucv_devices can be 0..8. This is a counter.
(c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES)

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

🎖@cveNotify

🚨 CVE-2026-53307
In the Linux kernel, the following vulnerability has been resolved:

pinctrl: pinconf-generic: Fully validate 'pinmux' property

The pinconf_generic_parse_dt_pinmux() assumes that the 'pinmux' property
is not empty when present. This might be not true. With that, the allocator
will give a special value in return and not NULL which lead to the crash
when trying to access that (invalid) memory. Fix that by fully validating
'pinmux' value, including its length.

🎖@cveNotify

🚨 CVE-2026-53308
In the Linux kernel, the following vulnerability has been resolved:

power: supply: max77705: Free allocated workqueue and fix removal order

Use devm interface for allocating workqueue to fix two bugs at the same
time:

1. Driver leaks the memory on remove(), because the workqueue is not
destroyed.

2. Driver allocates workqueue and then registers interrupt handlers
with devm interface. This means that probe error paths will not use a
reversed order, but first destroy the workqueue and then, via devm
release handlers, free the interrupt.

The interrupt handler schedules work on this exact workqueue, thus if
interrupt is hit in this short time window - after destroying
workqueue, but before devm() frees the interrupt - the schedulled
work will lead to use of freed memory.

Change is not equivalent in the workqueue itself: use non-legacy API
which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is
used to update power supply (power_supply_changed()) status, thus there
is no point to run it for memory reclaim. Note that dev_name() is not
directly used in second argument to prevent possible unlikely parsing
any "%" character in device name as format.

🎖@cveNotify

🚨 CVE-2026-53309
In the Linux kernel, the following vulnerability has been resolved:

ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison

The local-vs-remote region comparison loop uses '<=' instead of '<',
causing it to read one entry past the valid range of qr_regions. The
other loops in the same function correctly use '<'.

Fix the loop condition to use '<' for consistency and correctness.

🎖@cveNotify

🚨 CVE-2026-53310
In the Linux kernel, the following vulnerability has been resolved:

soc/tegra: cbb: Fix cross-fabric target timeout lookup

When a fabric receives an error interrupt, the error may have
occurred on a different fabric. The target timeout lookup was using
the wrong base address (cbb->regs) with offsets from a different
fabric's target map, causing a kernel page fault.

Unable to handle kernel paging request at virtual address ffff80000954cc00
pc : tegra234_cbb_get_tmo_slv+0xc/0x28
Call trace:
tegra234_cbb_get_tmo_slv+0xc/0x28
print_err_notifier+0x6c0/0x7d0
tegra234_cbb_isr+0xe4/0x1b4

Add tegra234_cbb_get_fabric() to look up the correct fabric device
using fab_id, and use its base address for accessing target timeout
registers.

🎖@cveNotify

🚨 CVE-2026-53311
In the Linux kernel, the following vulnerability has been resolved:

fuse: fix uninit-value in fuse_dentry_revalidate()

fuse_dentry_revalidate() may be called with a dentry that didn't had
->d_time initialised. The issue was found with KMSAN, where lookup_open()
calls __d_alloc(), followed by d_revalidate(), as shown below:

=====================================================
BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
d_revalidate fs/namei.c:1030 [inline]
lookup_open fs/namei.c:4405 [inline]
open_last_lookups fs/namei.c:4583 [inline]
path_openat+0x1614/0x64c0 fs/namei.c:4827
do_file_open+0x2aa/0x680 fs/namei.c:4859
[...]

Uninit was created at:
slab_post_alloc_hook mm/slub.c:4466 [inline]
slab_alloc_node mm/slub.c:4788 [inline]
kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807
__d_alloc+0x55/0xa00 fs/dcache.c:1740
d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604
lookup_open fs/namei.c:4398 [inline]
open_last_lookups fs/namei.c:4583 [inline]
path_openat+0x135f/0x64c0 fs/namei.c:4827
do_file_open+0x2aa/0x680 fs/namei.c:4859
[...]
=====================================================

🎖@cveNotify

🚨 CVE-2026-53312
In the Linux kernel, the following vulnerability has been resolved:

iommu/riscv: Remove overflows on the invalidation path

Since RISC-V supports a sign extended page table it should support
a gather->end of ULONG_MAX, but if this happens it will infinite loop
because of the overflow.

Also avoid overflow computing the length by moving the +1 to the other
side of the <

🎖@cveNotify

🚨 CVE-2026-53313
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths

In dc_dmub_srv_log_diagnostic_data() and
dc_dmub_srv_enable_dpia_trace().

Both functions check:

if (!dc_dmub_srv || !dc_dmub_srv->dmub)

and then call DC_LOG_ERROR() inside that block.

DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if
dc_dmub_srv is NULL, the logging itself can dereference a
NULL pointer and cause a crash.

Fix this by splitting the checks.

First check if dc_dmub_srv is NULL and return immediately.
Then check dc_dmub_srv->dmub and log the error only when
dc_dmub_srv is valid.

Fixes the below:
../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961)
../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166)

🎖@cveNotify

🚨 CVE-2026-53314
In the Linux kernel, the following vulnerability has been resolved:

padata: Put CPU offline callback in ONLINE section to allow failure

syzbot reported the following warning:

DEAD callback error for CPU1
WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614

at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux")
which tglx traced to padata_cpu_dead() given it's the only
sub-CPUHP_TEARDOWN_CPU callback that returns an error.

Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU
so move the CPU offline callback to the ONLINE section where failure is
possible.

🎖@cveNotify

🚨 CVE-2026-53315
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/ras: Fix NULL deref in ras_core_get_utc_second_timestamp()

ras_core_get_utc_second_timestamp() retrieves the current UTC timestamp
(in seconds since the Unix epoch) through a platform-specific RAS system
callback and is used for timestamping RAS error events.

The function checks ras_core in the conditional statement before calling
the sys_fn callback. However, when the condition fails, the function
prints an error message using ras_core->dev.

If ras_core is NULL, this can lead to a potential NULL pointer
dereference when accessing ras_core->dev.

Add an early NULL check for ras_core at the beginning of the function
and return 0 when the pointer is not valid. This prevents the
dereference and makes the control flow clearer.

🎖@cveNotify

🚨 CVE-2026-53317
In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7921: Place upper limit on station AID

Any station configured with an AID over 20 causes a firmware crash.
This situation occurred in our testing using an AP interface on 7922
hardware, with a modified hostapd, sourced from Mediatek's OpenWRT
feeds.

In stock hostapd, station AIDs begin counting at 1, and this
configuration is prevented with an upper limit on associated stations.
However, the modified hostapd began allocation at 65, which caused the
firmware to crash. This fix does not allow these AIDs to work, but will
prevent the firmware crash.

This crash was only seen on IFTYPE_AP interfaces, and the fix does not
appear to have an effect on IFTYPE_STATION behavior.

🎖@cveNotify

🚨 CVE-2026-53318
In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr()

Move the NULL check for 'sta' before dereferencing it to prevent a
possible crash.

🎖@cveNotify

🚨 CVE-2026-53319
In the Linux kernel, the following vulnerability has been resolved:

blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()

wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from
wbt_alloc() and wbt_init(). However, both are expected failure paths:

- wbt_alloc() can return NULL under memory pressure (-ENOMEM)
- wbt_init() can fail with -EBUSY if wbt is already registered

syzbot triggers this by injecting memory allocation failures during MTD
partition creation via ioctl(BLKPG), causing a spurious warning.

wbt_init_enable_default() is a best-effort initialization called from
blk_register_queue() with a void return type. Failure simply means the
disk operates without writeback throttling, which is harmless.

Replace WARN_ON_ONCE with plain if-checks, consistent with how
wbt_set_lat() in the same file already handles these failures. Add a
pr_warn() for the wbt_init() failure to retain diagnostic information
without triggering a full stack trace.

🎖@cveNotify

🚨 CVE-2026-53320
In the Linux kernel, the following vulnerability has been resolved:

nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()

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

However, bd_oblocknr 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 bd_oblocknr set to 0 causes the comparison to incorrectly
match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing
the dead block check and calling nilfs_bmap_mark() on a non-existent
block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering
the WARN_ON(ret == -ENOENT).

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

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

🎖@cveNotify

🚨 CVE-2026-53321
In the Linux kernel, the following vulnerability has been resolved:

io_uring/napi: cap busy_poll_to 10 msec

Currently there's no cap on the maximum amount of time that napi is
allowed to poll if no events are found, which can lead to kernel
complaints on a task being stuck as there's no conditional rescheduling
done within that loop.

Just cap it to 10 msec in total, that's already way above any kind of
sane value that will reap any benefits, yet low enough that it's
nowhere near being able to trigger preemption complaints.

🎖@cveNotify

🚨 CVE-2026-53322
In the Linux kernel, the following vulnerability has been resolved:

vfio/pci: Clean up DMABUFs before disabling function

On device shutdown, make vfio_pci_core_close_device() call
vfio_pci_dma_buf_cleanup() before the function is disabled via
vfio_pci_core_disable(). This ensures that all access via DMABUFs is
revoked before the function's BARs become inaccessible.

This fixes an issue where, if the function is disabled first, a tiny
window exists in which the function's MSE is cleared and yet BARs
could still be accessed via the DMABUF. The resources would also be
freed and up for grabs by a different driver.

🎖@cveNotify

🚨 CVE-2026-53323
In the Linux kernel, the following vulnerability has been resolved:

net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops

DSA replaces the conduit (master) device's ethtool_ops with its own
wrappers that aggregate stats from both the conduit and DSA switch
ports. Taking the lock again inside the DSA wrappers causes a deadlock.

Stumbled upon this when booting qemu with fbnic and CONFIG_NET_DSA_LOOP=y
(which looks like some kind of testing device that auto-populates the ports
of eth0). `ethtool -i` is enough to deadlock. This means we have basically zero
coverage for DSA stuff with real ops locked devs.

Remove the redundant netdev_lock_ops()/netdev_unlock_ops() calls from
the DSA conduit ethtool wrappers.

🎖@cveNotify

🚨 CVE-2026-53324
In the Linux kernel, the following vulnerability has been resolved:

net: mana: Use pci_name() for debugfs directory naming

Use pci_name(pdev) for the per-device debugfs directory instead of
hardcoded "0" for PFs and pci_slot_name(pdev->slot) for VFs. The
previous approach had two issues:

1. pci_slot_name() dereferences pdev->slot, which can be NULL for VFs
in environments like generic VFIO passthrough or nested KVM,
causing a NULL pointer dereference.

2. Multiple PFs would all use "0", and VFs across different PCI
domains or buses could share the same slot name, leading to
-EEXIST errors from debugfs_create_dir().

pci_name(pdev) returns the unique BDF address, is always valid, and is
unique across the system.

🎖@cveNotify