| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix potential data race at PCM memory allocation helpers
The PCM memory allocation helpers have a sanity check against too many
buffer allocations. However, the check is performed without a proper
lock and the allocation isn't serialized; this allows user to allocate
more memories than predefined max size.
Practically seen, this isn't really a big problem, as it's more or
less some "soft limit" as a sanity check, and it's not possible to
allocate unlimitedly. But it's still better to address this for more
consistent behavior.
The patch covers the size check in do_alloc_pages() with the
card->memory_mutex, and increases the allocated size there for
preventing the further overflow. When the actual allocation fails,
the size is decreased accordingly. |
| In the Linux kernel, the following vulnerability has been resolved:
md: init bioset in mddev_init
IO operations may be needed before md_run(), such as updating metadata
after writing sysfs. Without bioset, this triggers a NULL pointer
dereference as below:
BUG: kernel NULL pointer dereference, address: 0000000000000020
Call Trace:
md_update_sb+0x658/0xe00
new_level_store+0xc5/0x120
md_attr_store+0xc9/0x1e0
sysfs_kf_write+0x6f/0xa0
kernfs_fop_write_iter+0x141/0x2a0
vfs_write+0x1fc/0x5a0
ksys_write+0x79/0x180
__x64_sys_write+0x1d/0x30
x64_sys_call+0x2818/0x2880
do_syscall_64+0xa9/0x580
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Reproducer
```
mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd]
echo inactive > /sys/block/md0/md/array_state
echo 10 > /sys/block/md0/md/new_level
```
mddev_init() can only be called once per mddev, no need to test if bioset
has been initialized anymore. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmem: core: Fix memleak in nvmem_register()
dev_set_name will alloc memory for nvmem->dev.kobj.name in
nvmem_register, when nvmem_validate_keepouts failed, nvmem's
memory will be freed and return, but nobody will free memory
for nvmem->dev.kobj.name, there will be memleak, so moving
nvmem_validate_keepouts() after device_register() and let
the device core deal with cleaning name in error cases. |
| In the Linux kernel, the following vulnerability has been resolved:
xen: speed up grant-table reclaim
When a grant entry is still in use by the remote domain, Linux must put
it on a deferred list. Normally, this list is very short, because
the PV network and block protocols expect the backend to unmap the grant
first. However, Qubes OS's GUI protocol is subject to the constraints
of the X Window System, and as such winds up with the frontend unmapping
the window first. As a result, the list can grow very large, resulting
in a massive memory leak and eventual VM freeze.
To partially solve this problem, make the number of entries that the VM
will attempt to free at each iteration tunable. The default is still
10, but it can be overridden via a module parameter.
This is Cc: stable because (when combined with appropriate userspace
changes) it fixes a severe performance and stability problem for Qubes
OS users. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire-digi00x: prevent potential use after free
This code was supposed to return an error code if init_stream()
failed, but it instead freed dg00x->rx_stream and returned success.
This potentially leads to a use after free. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: aspeed - fix double free caused by devm
The clock obtained via devm_clk_get_enabled() is automatically managed
by devres and will be disabled and freed on driver detach. Manually
calling clk_disable_unprepare() in error path and remove function
causes double free.
Remove the manual clock cleanup in both aspeed_acry_probe()'s error
path and aspeed_acry_remove(). |
| In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: Fix use-after-free in vidtv_bridge_dvb_init()
KASAN reports a use-after-free:
BUG: KASAN: use-after-free in dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]
Call Trace:
...
dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]
vidtv_bridge_probe+0x7bf/0xa40 [dvb_vidtv_bridge]
platform_probe+0xb6/0x170
...
Allocated by task 1238:
...
dvb_register_device+0x1a7/0xa70 [dvb_core]
dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]
vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]
...
Freed by task 1238:
dvb_register_device+0x6d2/0xa70 [dvb_core]
dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]
vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]
...
It is because the error handling in vidtv_bridge_dvb_init() is wrong.
First, vidtv_bridge_dmx(dev)_init() will clean themselves when fail, but
goto fail_dmx(_dev): calls release functions again, which causes
use-after-free.
Also, in fail_fe, fail_tuner_probe and fail_demod_probe, j = i will cause
out-of-bound when i finished its loop (i == NUM_FE). And the loop
releasing is wrong, although now NUM_FE is 1 so it won't cause problem.
Fix this by correctly releasing everything. |
| In the Linux kernel, the following vulnerability has been resolved:
configfs: fix possible memory leak in configfs_create_dir()
kmemleak reported memory leaks in configfs_create_dir():
unreferenced object 0xffff888009f6af00 (size 192):
comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)
backtrace:
kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163)
configfs_register_subsystem (fs/configfs/dir.c:1857)
basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
do_one_initcall (init/main.c:1296)
do_init_module (kernel/module/main.c:2455)
...
unreferenced object 0xffff888003ba7180 (size 96):
comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)
backtrace:
kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194)
configfs_make_dirent (fs/configfs/dir.c:248)
configfs_create_dir (fs/configfs/dir.c:296)
configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)
configfs_register_subsystem (fs/configfs/dir.c:1881)
basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
do_one_initcall (init/main.c:1296)
do_init_module (kernel/module/main.c:2455)
...
This is because the refcount is not correct in configfs_make_dirent().
For normal stage, the refcount is changing as:
configfs_register_subsystem()
configfs_create_dir()
configfs_make_dirent()
configfs_new_dirent() # set s_count = 1
dentry->d_fsdata = configfs_get(sd); # s_count = 2
...
configfs_unregister_subsystem()
configfs_remove_dir()
remove_dir()
configfs_remove_dirent() # s_count = 1
dput() ...
*dentry_unlink_inode()*
configfs_d_iput() # s_count = 0, release
However, if we failed in configfs_create():
configfs_register_subsystem()
configfs_create_dir()
configfs_make_dirent() # s_count = 2
...
configfs_create() # fail
->out_remove:
configfs_remove_dirent(dentry)
configfs_put(sd) # s_count = 1
return PTR_ERR(inode);
There is no inode in the error path, so the configfs_d_iput() is lost
and makes sd and fragment memory leaked.
To fix this, when we failed in configfs_create(), manually call
configfs_put(sd) to keep the refcount correct. |
| In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix possible null-ptr-deref in ubi_free_volume()
It willl cause null-ptr-deref in the following case:
uif_init()
ubi_add_volume()
cdev_add() -> if it fails, call kill_volumes()
device_register()
kill_volumes() -> if ubi_add_volume() fails call this function
ubi_free_volume()
cdev_del()
device_unregister() -> trying to delete a not added device,
it causes null-ptr-deref
So in ubi_free_volume(), it delete devices whether they are added
or not, it will causes null-ptr-deref.
Handle the error case whlie calling ubi_add_volume() to fix this
problem. If add volume fails, set the corresponding vol to null,
so it can not be accessed in kill_volumes() and release the
resource in ubi_add_volume() error path. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fix memory leak in drm_client_target_cloned
dmt_mode is allocated and never freed in this function.
It was found with the ast driver, but most drivers using generic fbdev
setup are probably affected.
This fixes the following kmemleak report:
backtrace:
[<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm]
[<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm]
[<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm]
[<0000000010e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]
[<00000000909f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]
[<00000000063a69aa>] drm_client_register+0x169/0x240 [drm]
[<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast]
[<00000000987f19bb>] local_pci_probe+0xdc/0x180
[<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0
[<0000000000b85301>] process_one_work+0x8b7/0x1540
[<000000003375b17c>] worker_thread+0x70a/0xed0
[<00000000b0d43cd9>] kthread+0x29f/0x340
[<000000008d770833>] ret_from_fork+0x1f/0x30
unreferenced object 0xff11000333089a00 (size 128): |
| In the Linux kernel, the following vulnerability has been resolved:
acct: fix potential integer overflow in encode_comp_t()
The integer overflow is descripted with following codes:
> 317 static comp_t encode_comp_t(u64 value)
> 318 {
> 319 int exp, rnd;
......
> 341 exp <<= MANTSIZE;
> 342 exp += value;
> 343 return exp;
> 344 }
Currently comp_t is defined as type of '__u16', but the variable 'exp' is
type of 'int', so overflow would happen when variable 'exp' in line 343 is
greater than 65535. |
| In the Linux kernel, the following vulnerability has been resolved:
media: anysee: fix null-ptr-deref in anysee_master_xfer
In anysee_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach anysee_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
[hverkuil: add spaces around +] |
| In the Linux kernel, the following vulnerability has been resolved:
regulator: stm32-pwr: fix of_iomap leak
Smatch reports:
drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() warn:
'base' from of_iomap() not released on lines: 151,166.
In stm32_pwr_regulator_probe(), base is not released
when devm_kzalloc() fails to allocate memory or
devm_regulator_register() fails to register a new regulator device,
which may cause a leak.
To fix this issue, replace of_iomap() with
devm_platform_ioremap_resource(). devm_platform_ioremap_resource()
is a specialized function for platform devices.
It allows 'base' to be automatically released whether the probe
function succeeds or fails.
Besides, use IS_ERR(base) instead of !base
as the return value of devm_platform_ioremap_resource()
can either be a pointer to the remapped memory or
an ERR_PTR() encoded error code if the operation fails. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-mixer: us16x08: validate meter packet indices
get_meter_levels_from_urb() parses the 64-byte meter packets sent by
the device and fills the per-channel arrays meter_level[],
comp_level[] and master_level[] in struct snd_us16x08_meter_store.
Currently the function derives the channel index directly from the
meter packet (MUB2(meter_urb, s) - 1) and uses it to index those
arrays without validating the range. If the packet contains a
negative or out-of-range channel number, the driver may write past
the end of these arrays.
Introduce a local channel variable and validate it before updating the
arrays. We reject negative indices, limit meter_level[] and
comp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[]
updates with ARRAY_SIZE(master_level). |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()
In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just
to avoid crashing the whole kernel due to a filesystem corruption. |
| In the Linux kernel, the following vulnerability has been resolved:
fs: Protect reconfiguration of sb read-write from racing writes
The reconfigure / remount code takes a lot of effort to protect
filesystem's reconfiguration code from racing writes on remounting
read-only. However during remounting read-only filesystem to read-write
mode userspace writes can start immediately once we clear SB_RDONLY
flag. This is inconvenient for example for ext4 because we need to do
some writes to the filesystem (such as preparation of quota files)
before we can take userspace writes so we are clearing SB_RDONLY flag
before we are fully ready to accept userpace writes and syzbot has found
a way to exploit this [1]. Also as far as I'm reading the code
the filesystem remount code was protected from racing writes in the
legacy mount path by the mount's MNT_READONLY flag so this is relatively
new problem. It is actually fairly easy to protect remount read-write
from racing writes using sb->s_readonly_remount flag so let's just do
that instead of having to workaround these races in the filesystem code.
[1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/ |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()
The rtl8187_rx_cb() calculates the rx descriptor header address
by subtracting its size from the skb tail pointer.
However, it does not validate if the received packet
(skb->len from urb->actual_length) is large enough to contain this
header.
If a truncated packet is received, this will lead to a buffer
underflow, reading memory before the start of the skb data area,
and causing a kernel panic.
Add length checks for both rtl8187 and rtl8187b descriptor headers
before attempting to access them, dropping the packet cleanly if the
check fails. |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: limit the level of fs stacking for file-backed mounts
Otherwise, it could cause potential kernel stack overflow (e.g., EROFS
mounting itself). |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow
A static code analysis tool flagged the possibility of buffer overflow when
using copy_from_user() for a debugfs entry.
Currently, it is possible that copy_from_user() copies more bytes than what
would fit in the mybuf char array. Add a min() restriction check between
sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect
against buffer overflow. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix hard lockup when reading the rx_monitor from debugfs
During I/O and simultaneous cat of /sys/kernel/debug/lpfc/fnX/rx_monitor, a
hard lockup similar to the call trace below may occur.
The spin_lock_bh in lpfc_rx_monitor_report is not protecting from timer
interrupts as expected, so change the strength of the spin lock to _irq.
Kernel panic - not syncing: Hard LOCKUP
CPU: 3 PID: 110402 Comm: cat Kdump: loaded
exception RIP: native_queued_spin_lock_slowpath+91
[IRQ stack]
native_queued_spin_lock_slowpath at ffffffffb814e30b
_raw_spin_lock at ffffffffb89a667a
lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc]
lpfc_cmf_timer at ffffffffc0abbc67 [lpfc]
__hrtimer_run_queues at ffffffffb8184250
hrtimer_interrupt at ffffffffb8184ab0
smp_apic_timer_interrupt at ffffffffb8a026ba
apic_timer_interrupt at ffffffffb8a01c4f
[End of IRQ stack]
apic_timer_interrupt at ffffffffb8a01c4f
lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc]
lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc]
full_proxy_read at ffffffffb83e7fc3
vfs_read at ffffffffb833fe71
ksys_read at ffffffffb83402af
do_syscall_64 at ffffffffb800430b
entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad |
