| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
x86/lam: Disable ADDRESS_MASKING in most cases
Linear Address Masking (LAM) has a weakness related to transient
execution as described in the SLAM paper[1]. Unless Linear Address
Space Separation (LASS) is enabled this weakness may be exploitable.
Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST,
or when speculation mitigations have been disabled at compile time,
otherwise keep LAM disabled.
There are no processors in market that support LAM yet, so currently
nobody is affected by this issue.
[1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf
[2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/
[ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ] |
| In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: Fix use-after-free in gsm_cleanup_mux
BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0
drivers/tty/n_gsm.c:3160 [n_gsm]
Read of size 8 at addr ffff88815fe99c00 by task poc/3379
CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56
Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
<TASK>
gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
__pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]
__pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389
update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500
__pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846
__rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161
gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
_raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107
__pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]
ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195
ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79
__pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338
__pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805
tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818
Allocated by task 65:
gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]
gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]
gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]
gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]
tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391
tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39
flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445
process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229
worker_thread+0x3dc/0x950 kernel/workqueue.c:3391
kthread+0x2a3/0x370 kernel/kthread.c:389
ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257
Freed by task 3367:
kfree+0x126/0x420 mm/slub.c:4580
gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818
[Analysis]
gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux
can be freed by multi threads through ioctl,which leads
to the occurrence of uaf. Protect it by gsm tx lock. |
| In the Linux kernel, the following vulnerability has been resolved:
ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition
In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev
function, then &sndev->check_link_status_work is bound with
check_link_status_work. switchtec_ntb_link_notification may be called
to start the work.
If we remove the module which will call switchtec_ntb_remove to make
cleanup, it will free sndev through kfree(sndev), while the work
mentioned above will be used. The sequence of operations that may lead
to a UAF bug is as follows:
CPU0 CPU1
| check_link_status_work
switchtec_ntb_remove |
kfree(sndev); |
| if (sndev->link_force_down)
| // use sndev
Fix it by ensuring that the work is canceled before proceeding with
the cleanup in switchtec_ntb_remove. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in async decryption
Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.
Reproducer:
# mount.cifs -o ...,seal,esize=1 //srv/share /mnt
# dd if=/mnt/largefile of=/dev/null
...
[ 194.196391] ==================================================================
[ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
[ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
[ 194.197707]
[ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43
[ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
[ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
[ 194.200032] Call Trace:
[ 194.200191] <TASK>
[ 194.200327] dump_stack_lvl+0x4e/0x70
[ 194.200558] ? gf128mul_4k_lle+0xc1/0x110
[ 194.200809] print_report+0x174/0x505
[ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 194.201352] ? srso_return_thunk+0x5/0x5f
[ 194.201604] ? __virt_addr_valid+0xdf/0x1c0
[ 194.201868] ? gf128mul_4k_lle+0xc1/0x110
[ 194.202128] kasan_report+0xc8/0x150
[ 194.202361] ? gf128mul_4k_lle+0xc1/0x110
[ 194.202616] gf128mul_4k_lle+0xc1/0x110
[ 194.202863] ghash_update+0x184/0x210
[ 194.203103] shash_ahash_update+0x184/0x2a0
[ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10
[ 194.203651] ? srso_return_thunk+0x5/0x5f
[ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340
[ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140
[ 194.204434] crypt_message+0xec1/0x10a0 [cifs]
[ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs]
[ 194.208507] ? srso_return_thunk+0x5/0x5f
[ 194.209205] ? srso_return_thunk+0x5/0x5f
[ 194.209925] ? srso_return_thunk+0x5/0x5f
[ 194.210443] ? srso_return_thunk+0x5/0x5f
[ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs]
[ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
[ 194.214670] ? srso_return_thunk+0x5/0x5f
[ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs]
This is because TFM is being used in parallel.
Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).
Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: asihpi: Fix potential OOB array access
ASIHPI driver stores some values in the static array upon a response
from the driver, and its index depends on the firmware. We shouldn't
trust it blindly.
This patch adds a sanity check of the array index to fit in the array
size. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/stm: Avoid use-after-free issues with crtc and plane
ltdc_load() calls functions drm_crtc_init_with_planes(),
drm_universal_plane_init() and drm_encoder_init(). These functions
should not be called with parameters allocated with devm_kzalloc()
to avoid use-after-free issues [1].
Use allocations managed by the DRM framework.
Found by Linux Verification Center (linuxtesting.org).
[1]
https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/ |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: pxafb: Fix possible use after free in pxafb_task()
In the pxafb_probe function, it calls the pxafb_init_fbinfo function,
after which &fbi->task is associated with pxafb_task. Moreover,
within this pxafb_init_fbinfo function, the pxafb_blank function
within the &pxafb_ops struct is capable of scheduling work.
If we remove the module which will call pxafb_remove to make cleanup,
it will call unregister_framebuffer function which can call
do_unregister_framebuffer to free fbi->fb through
put_fb_info(fb_info), while the work mentioned above will be used.
The sequence of operations that may lead to a UAF bug is as follows:
CPU0 CPU1
| pxafb_task
pxafb_remove |
unregister_framebuffer(info) |
do_unregister_framebuffer(fb_info) |
put_fb_info(fb_info) |
// free fbi->fb | set_ctrlr_state(fbi, state)
| __pxafb_lcd_power(fbi, 0)
| fbi->lcd_power(on, &fbi->fb.var)
| //use fbi->fb
Fix it by ensuring that the work is canceled before proceeding
with the cleanup in pxafb_remove.
Note that only root user can remove the driver at runtime. |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: add bounds checking to ocfs2_xattr_find_entry()
Add a paranoia check to make sure it doesn't stray beyond valid memory
region containing ocfs2 xattr entries when scanning for a match. It will
prevent out-of-bound access in case of crafted images. |
| In the Linux kernel, the following vulnerability has been resolved:
smack: tcp: ipv4, fix incorrect labeling
Currently, Smack mirrors the label of incoming tcp/ipv4 connections:
when a label 'foo' connects to a label 'bar' with tcp/ipv4,
'foo' always gets 'foo' in returned ipv4 packets. So,
1) returned packets are incorrectly labeled ('foo' instead of 'bar')
2) 'bar' can write to 'foo' without being authorized to write.
Here is a scenario how to see this:
* Take two machines, let's call them C and S,
with active Smack in the default state
(no settings, no rules, no labeled hosts, only builtin labels)
* At S, add Smack rule 'foo bar w'
(labels 'foo' and 'bar' are instantiated at S at this moment)
* At S, at label 'bar', launch a program
that listens for incoming tcp/ipv4 connections
* From C, at label 'foo', connect to the listener at S.
(label 'foo' is instantiated at C at this moment)
Connection succeedes and works.
* Send some data in both directions.
* Collect network traffic of this connection.
All packets in both directions are labeled with the CIPSO
of the label 'foo'. Hence, label 'bar' writes to 'foo' without
being authorized, and even without ever being known at C.
If anybody cares: exactly the same happens with DCCP.
This behavior 1st manifested in release 2.6.29.4 (see Fixes below)
and it looks unintentional. At least, no explanation was provided.
I changed returned packes label into the 'bar',
to bring it into line with the Smack documentation claims. |
| In the Linux kernel, the following vulnerability has been resolved:
um: line: always fill *error_out in setup_one_line()
The pointer isn't initialized by callers, but I have
encountered cases where it's still printed; initialize
it in all possible cases in setup_one_line(). |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas()
Smatch warns:
arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential
spectre issue 'args.args' [r] (local cap)
The 'nargs' and 'nret' locals come directly from a user-supplied
buffer and are used as indexes into a small stack-based array and as
inputs to copy_to_user() after they are subject to bounds checks.
Use array_index_nospec() after the bounds checks to clamp these values
for speculative execution. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup
report_fixup for the Cougar 500k Gaming Keyboard was not verifying
that the report descriptor size was correct before accessing it |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix the Out-of-bounds read warning
using index i - 1U may beyond element index
for mc_data[] when i = 0. |
| In the Linux kernel, the following vulnerability has been resolved:
parisc: fix a possible DMA corruption
ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be
possible that two unrelated 16-byte allocations share a cache line. If
one of these allocations is written using DMA and the other is written
using cached write, the value that was written with DMA may be
corrupted.
This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 -
that's the largest possible cache line size.
As different parisc microarchitectures have different cache line size, we
define arch_slab_minalign(), cache_line_size() and
dma_get_cache_alignment() so that the kernel may tune slab cache
parameters dynamically, based on the detected cache line size. |
| In the Linux kernel, the following vulnerability has been resolved:
media: xc2028: avoid use-after-free in load_firmware_cb()
syzkaller reported use-after-free in load_firmware_cb() [1].
The reason is because the module allocated a struct tuner in tuner_probe(),
and then the module initialization failed, the struct tuner was released.
A worker which created during module initialization accesses this struct
tuner later, it caused use-after-free.
The process is as follows:
task-6504 worker_thread
tuner_probe <= alloc dvb_frontend [2]
...
request_firmware_nowait <= create a worker
...
tuner_remove <= free dvb_frontend
...
request_firmware_work_func <= the firmware is ready
load_firmware_cb <= but now the dvb_frontend has been freed
To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is
null, report a warning and just return.
[1]:
==================================================================
BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0
Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504
Call trace:
load_firmware_cb+0x1310/0x17a0
request_firmware_work_func+0x128/0x220
process_one_work+0x770/0x1824
worker_thread+0x488/0xea0
kthread+0x300/0x430
ret_from_fork+0x10/0x20
Allocated by task 6504:
kzalloc
tuner_probe+0xb0/0x1430
i2c_device_probe+0x92c/0xaf0
really_probe+0x678/0xcd0
driver_probe_device+0x280/0x370
__device_attach_driver+0x220/0x330
bus_for_each_drv+0x134/0x1c0
__device_attach+0x1f4/0x410
device_initial_probe+0x20/0x30
bus_probe_device+0x184/0x200
device_add+0x924/0x12c0
device_register+0x24/0x30
i2c_new_device+0x4e0/0xc44
v4l2_i2c_new_subdev_board+0xbc/0x290
v4l2_i2c_new_subdev+0xc8/0x104
em28xx_v4l2_init+0x1dd0/0x3770
Freed by task 6504:
kfree+0x238/0x4e4
tuner_remove+0x144/0x1c0
i2c_device_remove+0xc8/0x290
__device_release_driver+0x314/0x5fc
device_release_driver+0x30/0x44
bus_remove_device+0x244/0x490
device_del+0x350/0x900
device_unregister+0x28/0xd0
i2c_unregister_device+0x174/0x1d0
v4l2_device_unregister+0x224/0x380
em28xx_v4l2_init+0x1d90/0x3770
The buggy address belongs to the object at ffff8000d7ca2000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 776 bytes inside of
2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
The buggy address belongs to the page:
page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0
flags: 0x7ff800000000100(slab)
raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
[2]
Actually, it is allocated for struct tuner, and dvb_frontend is inside. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: vhci-hcd: Do not drop references before new references are gained
At a few places the driver carries stale pointers
to references that can still be used. Make sure that does not happen.
This strictly speaking closes ZDI-CAN-22273, though there may be
similar races in the driver. |
| In the Linux kernel, the following vulnerability has been resolved:
dev/parport: fix the array out-of-bounds risk
Fixed array out-of-bounds issues caused by sprintf
by replacing it with snprintf for safer data copying,
ensuring the destination buffer is not overflowed.
Below is the stack trace I encountered during the actual issue:
[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]
[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2
[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp
[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun
PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024
[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0
[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20
[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c
[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc
[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38
[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport] |
| In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix inode number range checks
Patch series "nilfs2: fix potential issues related to reserved inodes".
This series fixes one use-after-free issue reported by syzbot, caused by
nilfs2's internal inode being exposed in the namespace on a corrupted
filesystem, and a couple of flaws that cause problems if the starting
number of non-reserved inodes written in the on-disk super block is
intentionally (or corruptly) changed from its default value.
This patch (of 3):
In the current implementation of nilfs2, "nilfs->ns_first_ino", which
gives the first non-reserved inode number, is read from the superblock,
but its lower limit is not checked.
As a result, if a number that overlaps with the inode number range of
reserved inodes such as the root directory or metadata files is set in the
super block parameter, the inode number test macros (NILFS_MDT_INODE and
NILFS_VALID_INODE) will not function properly.
In addition, these test macros use left bit-shift calculations using with
the inode number as the shift count via the BIT macro, but the result of a
shift calculation that exceeds the bit width of an integer is undefined in
the C specification, so if "ns_first_ino" is set to a large value other
than the default value NILFS_USER_INO (=11), the macros may potentially
malfunction depending on the environment.
Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and
by preventing bit shifts equal to or greater than the NILFS_USER_INO
constant in the inode number test macros.
Also, change the type of "ns_first_ino" from signed integer to unsigned
integer to avoid the need for type casting in comparisons such as the
lower bound check introduced this time. |
| In the Linux kernel, the following vulnerability has been resolved:
nilfs2: add missing check for inode numbers on directory entries
Syzbot reported that mounting and unmounting a specific pattern of
corrupted nilfs2 filesystem images causes a use-after-free of metadata
file inodes, which triggers a kernel bug in lru_add_fn().
As Jan Kara pointed out, this is because the link count of a metadata file
gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),
tries to delete that inode (ifile inode in this case).
The inconsistency occurs because directories containing the inode numbers
of these metadata files that should not be visible in the namespace are
read without checking.
Fix this issue by treating the inode numbers of these internal files as
errors in the sanity check helper when reading directory folios/pages.
Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer
analysis. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: topology: Fix references to freed memory
Most users after parsing a topology file, release memory used by it, so
having pointer references directly into topology file contents is wrong.
Use devm_kmemdup(), to allocate memory as needed. |
