Security Vulnerabilities
- CVEs Published In May 2024
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU
but the header isn't fully there, we can end up reading
data out of bounds, only to discard later. Make this a
bit more careful and check if the subframe header can
even be present.
In the Linux kernel, the following vulnerability has been resolved:
pstore/zone: Add a null pointer check to the psz_kmsg_read
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: adding lock to protect encoder context list
Add a lock for the ctx_list, to avoid accessing a NULL pointer
within the 'vpu_enc_ipi_handler' function when the ctx_list has
been deleted due to an unexpected behavior on the SCP IP block.
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: adding lock to protect decoder context list
Add a lock for the ctx_list, to avoid accessing a NULL pointer
within the 'vpu_dec_ipi_handler' function when the ctx_list has
been deleted due to an unexpected behavior on the SCP IP block.
Hardware name: Google juniper sku16 board (DT)
pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--)
pc : vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec]
lr : scp_ipi_handler+0xd0/0x194 [mtk_scp]
sp : ffffffc0131dbbd0
x29: ffffffc0131dbbd0 x28: 0000000000000000
x27: ffffff9bb277f348 x26: ffffff9bb242ad00
x25: ffffffd2d440d3b8 x24: ffffffd2a13ff1d4
x23: ffffff9bb7fe85a0 x22: ffffffc0133fbdb0
x21: 0000000000000010 x20: ffffff9b050ea328
x19: ffffffc0131dbc08 x18: 0000000000001000
x17: 0000000000000000 x16: ffffffd2d461c6e0
x15: 0000000000000242 x14: 000000000000018f
x13: 000000000000004d x12: 0000000000000000
x11: 0000000000000001 x10: fffffffffffffff0
x9 : ffffff9bb6e793a8 x8 : 0000000000000000
x7 : 0000000000000000 x6 : 000000000000003f
x5 : 0000000000000040 x4 : fffffffffffffff0
x3 : 0000000000000020 x2 : ffffff9bb6e79080
x1 : 0000000000000010 x0 : ffffffc0131dbc08
Call trace:
vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec (HASH:6c3f 2)]
scp_ipi_handler+0xd0/0x194 [mtk_scp (HASH:7046 3)]
mt8183_scp_irq_handler+0x44/0x88 [mtk_scp (HASH:7046 3)]
scp_irq_handler+0x48/0x90 [mtk_scp (HASH:7046 3)]
irq_thread_fn+0x38/0x94
irq_thread+0x100/0x1c0
kthread+0x140/0x1fc
ret_from_fork+0x10/0x30
Code: 54000088 f94ca50a eb14015f 54000060 (f9400108)
---[ end trace ace43ce36cbd5c93 ]---
Kernel panic - not syncing: Oops: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: 0x12c4000000 from 0xffffffc010000000
PHYS_OFFSET: 0xffffffe580000000
CPU features: 0x08240002,2188200c
Memory Limit: none
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix oops when HEVC init fails
The stateless HEVC decoder saves the instance pointer in the context
regardless if the initialization worked or not. This caused a use after
free, when the pointer is freed in case of a failure in the deinit
function.
Only store the instance pointer when the initialization was successful,
to solve this issue.
Hardware name: Acer Tomato (rev3 - 4) board (DT)
pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]
lr : vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]
sp : ffff80008750bc20
x29: ffff80008750bc20 x28: ffff1299f6d70000 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
x23: ffff80008750bc98 x22: 000000000000a003 x21: ffffd45c4cfae000
x20: 0000000000000010 x19: ffff1299fd668310 x18: 000000000000001a
x17: 000000040044ffff x16: ffffd45cb15dc648 x15: 0000000000000000
x14: ffff1299c08da1c0 x13: ffffd45cb1f87a10 x12: ffffd45cb2f5fe80
x11: 0000000000000001 x10: 0000000000001b30 x9 : ffffd45c4d12b488
x8 : 1fffe25339380d81 x7 : 0000000000000001 x6 : ffff1299c9c06c00
x5 : 0000000000000132 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000010 x1 : ffff80008750bc98 x0 : 0000000000000000
Call trace:
vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]
vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]
vpu_dec_deinit+0x1c/0x30 [mtk_vcodec_dec]
vdec_hevc_slice_deinit+0x30/0x98 [mtk_vcodec_dec]
vdec_if_deinit+0x38/0x68 [mtk_vcodec_dec]
mtk_vcodec_dec_release+0x20/0x40 [mtk_vcodec_dec]
fops_vcodec_release+0x64/0x118 [mtk_vcodec_dec]
v4l2_release+0x7c/0x100
__fput+0x80/0x2d8
__fput_sync+0x58/0x70
__arm64_sys_close+0x40/0x90
invoke_syscall+0x50/0x128
el0_svc_common.constprop.0+0x48/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x38/0xd8
el0t_64_sync_handler+0xc0/0xc8
el0t_64_sync+0x1a8/0x1b0
Code: d503201f f9401660 b900127f b900227f (f9400400)
In the Linux kernel, the following vulnerability has been resolved:
fbmon: prevent division by zero in fb_videomode_from_videomode()
The expression htotal * vtotal can have a zero value on
overflow. It is necessary to prevent division by zero like in
fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace.
In the Linux kernel, the following vulnerability has been resolved:
block: prevent division by zero in blk_rq_stat_sum()
The expression dst->nr_samples + src->nr_samples may
have zero value on overflow. It is necessary to add
a check to avoid division by zero.
Found by Linux Verification Center (linuxtesting.org) with Svace.
In the Linux kernel, the following vulnerability has been resolved:
rcu/nocb: Fix WARN_ON_ONCE() in the rcu_nocb_bypass_lock()
For the kernels built with CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y and
CONFIG_RCU_LAZY=y, the following scenarios will trigger WARN_ON_ONCE()
in the rcu_nocb_bypass_lock() and rcu_nocb_wait_contended() functions:
CPU2 CPU11
kthread
rcu_nocb_cb_kthread ksys_write
rcu_do_batch vfs_write
rcu_torture_timer_cb proc_sys_write
__kmem_cache_free proc_sys_call_handler
kmemleak_free drop_caches_sysctl_handler
delete_object_full drop_slab
__delete_object shrink_slab
put_object lazy_rcu_shrink_scan
call_rcu rcu_nocb_flush_bypass
__call_rcu_commn rcu_nocb_bypass_lock
raw_spin_trylock(&rdp->nocb_bypass_lock) fail
atomic_inc(&rdp->nocb_lock_contended);
rcu_nocb_wait_contended WARN_ON_ONCE(smp_processor_id() != rdp->cpu);
WARN_ON_ONCE(atomic_read(&rdp->nocb_lock_contended)) |
|_ _ _ _ _ _ _ _ _ _same rdp and rdp->cpu != 11_ _ _ _ _ _ _ _ _ __|
Reproduce this bug with "echo 3 > /proc/sys/vm/drop_caches".
This commit therefore uses rcu_nocb_try_flush_bypass() instead of
rcu_nocb_flush_bypass() in lazy_rcu_shrink_scan(). If the nocb_bypass
queue is being flushed, then rcu_nocb_try_flush_bypass will return
directly.
In the Linux kernel, the following vulnerability has been resolved:
sysv: don't call sb_bread() with pointers_lock held
syzbot is reporting sleep in atomic context in SysV filesystem [1], for
sb_bread() is called with rw_spinlock held.
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug
and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by
"Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made
this problem easier to hit).
Al Viro suggested that why not to do like get_branch()/get_block()/
find_shared() in Minix filesystem does. And doing like that is almost a
revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
from with find_shared() is called without write_lock(&pointers_lock).
In the Linux kernel, the following vulnerability has been resolved:
dma-buf: Fix NULL pointer dereference in sanitycheck()
If due to a memory allocation failure mock_chain() returns NULL, it is
passed to dma_fence_enable_sw_signaling() resulting in NULL pointer
dereference there.
Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds.
Found by Linux Verification Center (linuxtesting.org) with SVACE.