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]
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.
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.
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.
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.
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.
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.
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.
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.
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
[...]
=====================================================