f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.
creating a large files during checkpoint disable until it runs out of
space and then delete it, then remount to enable checkpoint again, and
then unmount the filesystem triggers the f2fs_bug_on as below:
------------[ cut here ]------------
kernel BUG at fs/f2fs/inode.c:896!
CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:f2fs_evict_inode+0x58c/0x610
Call Trace:
__die_body+0x15/0x60
die+0x33/0x50
do_trap+0x10a/0x120
btrfs: ref-verify: fix use-after-free after invalid ref action
In the Linux kernel, the following vulnerability has been resolved:
btrfs: ref-verify: fix use-after-free after invalid ref action
At btrfs_ref_tree_mod() after we successfully inserted the new ref entry
(local variable 'ref') into the respective block entry's rbtree (local
variable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,
we error out and free the ref entry without removing it from the block
entry's rbtree. Then in the error path of btrfs_ref_tree_mod() we call
btrfs_free_ref_cache(), which iterates over all block entries and then
calls free_block_entry() for each one, and there we will trigger a
use-after-free whe
media: imx-jpeg: Set video drvdata before register video device
In the Linux kernel, the following vulnerability has been resolved:
media: imx-jpeg: Set video drvdata before register video device
The video drvdata should be set before the video device is registered,
otherwise video_drvdata() may return NULL in the open() file ops, and led
to oops.
media: i2c: tc358743: Fix crash in the probe error path when using polling
In the Linux kernel, the following vulnerability has been resolved:
media: i2c: tc358743: Fix crash in the probe error path when using polling
If an error occurs in the probe() function, we should remove the polling
timer that was alarmed earlier, otherwise the timer is called with
arguments that are already freed, which results in a crash.
------------[ cut here ]------------
WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268
Modules linked in:
CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226
Hardware name: Diasom DS-RK3568-SOM-EVB (DT)
pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc
media: imx-jpeg: Ensure power suppliers be suspended before detach them
In the Linux kernel, the following vulnerability has been resolved:
media: imx-jpeg: Ensure power suppliers be suspended before detach them
The power suppliers are always requested to suspend asynchronously,
dev_pm_domain_detach() requires the caller to ensure proper
synchronization of this function with power management callbacks.
otherwise the detach may led to kernel panic, like below:
[ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040
[ 1457.116777] Mem abort info:
[ 1457.119589] ESR = 0x0000000096000004
[ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1457.128692] SET =
media: ts2020: fix null-ptr-deref in ts2020_probe()
In the Linux kernel, the following vulnerability has been resolved:
media: ts2020: fix null-ptr-deref in ts2020_probe()
KASAN reported a null-ptr-deref issue when executing the following
command:
# echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]
RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809
RDX: 0000000000
media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()
In the Linux kernel, the following vulnerability has been resolved:
media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()
The buffer in the loop should be released under the exception path,
otherwise there may be a memory leak here.
To mitigate this, free the buffer when allegro_alloc_buffer fails.
ovl: Filter invalid inodes with missing lookup function
In the Linux kernel, the following vulnerability has been resolved:
ovl: Filter invalid inodes with missing lookup function
Add a check to the ovl_dentry_weird() function to prevent the
processing of directory inodes that lack the lookup function.
This is important because such inodes can cause errors in overlayfs
when passed to the lowerstack.
ftrace: Fix regression with module command in stack_trace_filter
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix regression with module command in stack_trace_filter
When executing the following command:
# echo "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter
The current mod command causes a null pointer dereference. While commit
0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter")
has addressed part of the issue, it left a corner case unhandled, which still
results in a kernel crash.
iommu/arm-smmu: Defer probe of clients after smmu device bound
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu: Defer probe of clients after smmu device bound
Null pointer dereference occurs due to a race between smmu
driver probe and client driver probe, when of_dma_configure()
for client is called after the iommu_device_register() for smmu driver
probe has executed but before the driver_bound() for smmu driver
has been called.
Following is how the race occurs:
T1:Smmu device probe T2: Client device probe
really_probe()
arm_smmu_device_probe()
iommu_device_register()
really_probe()
platform_dma_configure()
of_dma_configure()
of_dma_configure_i
ad7780: fix division by zero in ad7780_write_raw()
In the Linux kernel, the following vulnerability has been resolved:
ad7780: fix division by zero in ad7780_write_raw()
In the ad7780_write_raw() , val2 can be zero, which might lead to a
division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()
is based on iio_info's write_raw. While val is explicitly declared that
can be zero (in read mode), val2 is not specified to be non-zero.
i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()
In the Linux kernel, the following vulnerability has been resolved:
i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()
if (dev->boardinfo && dev->boardinfo->init_dyn_addr)
^^^ here check "init_dyn_addr"
i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...)
^^^^
free "dyn_addr"
Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".
In the Linux kernel, the following vulnerability has been resolved:
nfsd: make sure exp active before svc_export_show
The function `e_show` was called with protection from RCU. This only
ensures that `exp` will not be freed. Therefore, the reference count for
`exp` can drop to zero, which will trigger a refcount use-after-free
warning when `exp_get` is called. To resolve this issue, use
`cache_get_rcu` to ensure that `exp` remains active.
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 3 PID: 819 at lib/refcount.c:25
refcount_warn_saturate+0xb1/0x120
CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted
hfsplus: don't query the device logical block size multiple times
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't query the device logical block size multiple times
Devices block sizes may change. One of these cases is a loop device by
using ioctl LOOP_SET_BLOCK_SIZE.
While this may cause other issues like IO being rejected, in the case of
hfsplus, it will allocate a block by using that size and potentially write
out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the
latter function reads a different io_size.
Using a new min_io_size initally set to sb_min_blocksize works for the
purposes of the original fix, since it will be set to the max between
HFS
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
Replace one-element array with a flexible-array member in `struct
mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------
[ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)
[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_n
ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long
waiting. OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long. It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed(). This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.
ALSA: us122l: Use snd_card_free_when_closed() at disconnection
In the Linux kernel, the following vulnerability has been resolved:
ALSA: us122l: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long
waiting. OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long. It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed(). This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.
The
ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
In the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
The USB disconnect callback is supposed to be short and not too-long
waiting. OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long. It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.
An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed(). This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.
This
In the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: Release resources at card release
The current 6fire code tries to release the resources right after the
call of usb6fire_chip_abort(). But at this moment, the card object
might be still in use (as we're calling snd_card_free_when_closed()).
For avoid potential UAFs, move the release of resources to the card's
private_free instead of the manual call of usb6fire_chip_destroy() at
the USB disconnect callback.
Bluetooth: fix use-after-free in device_for_each_child()
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix use-after-free in device_for_each_child()
Syzbot has reported the following KASAN splat:
BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0
Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980
CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x100/0x190
? device_for_each_child+0x18f/0x1a0
print_report+0x13a/0x4cb
? __virt_addr_valid+0x5e/0x590
? __phys_addr+0xc6/0x