Linux: >> Linux Kernel >> 2.0.20 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit
mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000.
Because of the way __pa() works we have:
__pa(0x8000000000000000) == 0, and therefore
virt_to_pfn(0x8000000000000000) == 0, and therefore
virt_addr_valid(0x8000000000000000) == true
Which is wrong, virt_addr_valid() should be false for vmalloc space.
In fact all vmalloc addresses that alias with a valid PFN will return
true from virt_addr_valid(). That can cause bugs with hardened usercopy
as described below by Kefeng Wang:
When running ethtool eth0 on 64-bit Book3E, a BUG occurred:
usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!
kernel BUG at mm/usercopy.c:99
...
usercopy_abort+0x64/0xa0 (unreliable)
__check_heap_object+0x168/0x190
__check_object_size+0x1a0/0x200
dev_ethtool+0x2494/0x2b20
dev_ioctl+0x5d0/0x770
sock_do_ioctl+0xf0/0x1d0
sock_ioctl+0x3ec/0x5a0
__se_sys_ioctl+0xf0/0x160
system_call_exception+0xfc/0x1f0
system_call_common+0xf8/0x200
The code shows below,
data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));
copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))
The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true
on 64-bit Book3E, which leads to the panic.
As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va
and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in
the virt_addr_valid() for 64-bit, also add upper limit check to make
sure the virt is below high_memory.
Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start
of lowmem, high_memory is the upper low virtual address, the check is
suitable for 32-bit, this will fix the issue mentioned in commit
602946ec2f90 ("powerpc: Set max_mapnr correctly") too.
On 32-bit there is a similar problem with high memory, that was fixed in
commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that
commit breaks highmem and needs to be reverted.
We can't easily fix __pa(), we have code that relies on its current
behaviour. So for now add extra checks to virt_addr_valid().
For 64-bit Book3S the extra checks are not necessary, the combination of
virt_to_pfn() and pfn_valid() should yield the correct result, but they
are harmless.
[mpe: Add additional change log detail]
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcmu: Fix possible page UAF
tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not
take refcount properly and just returns page pointer. When
tcmu_try_get_data_page() returns, the returned page may have been freed by
tcmu_blocks_release().
We need to get_page() under cmdr_lock to avoid concurrent
tcmu_blocks_release().
CVSS Score
7.8
EPSS Score
0.001
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Deactivate sysctl_record_panic_msg by default in isolated guests
hv_panic_page might contain guest-sensitive information, do not dump it
over to Hyper-V by default in isolated guests.
While at it, update some comments in hyperv_{panic,die}_event().
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Check for potential null return of kmalloc_array()
As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference.
Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
samples/landlock: Fix path_list memory leak
Clang static analysis reports this error
sandboxer.c:134:8: warning: Potential leak of memory
pointed to by 'path_list'
ret = 0;
^
path_list is allocated in parse_path() but never freed.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
media: staging: media: zoran: move videodev alloc
Move some code out of zr36057_init() and create new functions for handling
zr->video_dev. This permit to ease code reading and fix a zr->video_dev
memory leak.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com
On the case tmp_dcim=1, the index of buffer is miscalculated.
This generate a NULL pointer dereference later.
So let's fix the calcul and add a check to prevent this to reappear.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
Revert "Revert "block, bfq: honor already-setup queue merges""
A crash [1] happened to be triggered in conjunction with commit
2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The
latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq:
honor already-setup queue merges""). Yet, the reverted commit was not
the one introducing the bug. In fact, it actually triggered a UAF
introduced by a different commit, and now fixed by commit d29bd41428cf
("block, bfq: reset last_bfqq_created on group change").
So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq:
honor already-setup queue merges") out. This commit restores it.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=214503
CVSS Score
7.8
EPSS Score
0.001
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: cirrusfb: check pixclock to avoid divide by zero
Do a sanity check on pixclock value to avoid divide by zero.
If the pixclock value is zero, the cirrusfb driver will round up
pixclock to get the derived frequency as close to maxclock as
possible.
Syzkaller reported a divide error in cirrusfb_check_pixclock.
divide error: 0000 [#1] SMP KASAN PTI
CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2
RIP: 0010:cirrusfb_check_var+0x6f1/0x1260
Call Trace:
fb_set_var+0x398/0xf90
do_fb_ioctl+0x4b8/0x6f0
fb_ioctl+0xeb/0x130
__x64_sys_ioctl+0x19d/0x220
do_syscall_64+0x3a/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow
Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.
CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
chan->adapter.name by copying name without checking the length.
2. parameter_as_source: Note: This defect has an elevated risk because the
source argument is a parameter of the current function.
89 strcpy(chan->adapter.name, name);
Fix this warning by using strscpy() which will silence the warning and
prevent any future buffer overflows should the names used to identify the
channel become much longer.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-02-26