Security Vulnerabilities - CVEs Published In January 2025
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add check for granularity in dml ceil/floor helpers
[Why]
Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()
should check for granularity is non zero to avoid assert and
divide-by-zero error in dcn_bw_ functions.
[How]
Add check for granularity 0.
(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)
CVSS Score
5.5
EPSS Score
0.001
Published
2025-01-19
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zlib: fix avail_in bytes for s390 zlib HW compression path
Since the input data length passed to zlib_compress_folios() can be
arbitrary, always setting strm.avail_in to a multiple of PAGE_SIZE may
cause read-in bytes to exceed the input range. Currently this triggers
an assert in btrfs_compress_folios() on the debug kernel (see below).
Fix strm.avail_in calculation for S390 hardware acceleration path.
assertion failed: *total_in <= orig_len, in fs/btrfs/compression.c:1041
------------[ cut here ]------------
kernel BUG at fs/btrfs/compression.c:1041!
monitor event: 0040 ilc:2 [#1] PREEMPT SMP
CPU: 16 UID: 0 PID: 325 Comm: kworker/u273:3 Not tainted 6.13.0-20241204.rc1.git6.fae3b21430ca.300.fc41.s390x+debug #1
Hardware name: IBM 3931 A01 703 (z/VM 7.4.0)
Workqueue: btrfs-delalloc btrfs_work_helper
Krnl PSW : 0704d00180000000 0000021761df6538 (btrfs_compress_folios+0x198/0x1a0)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3
Krnl GPRS: 0000000080000000 0000000000000001 0000000000000047 0000000000000000
0000000000000006 ffffff01757bb000 000001976232fcc0 000000000000130c
000001976232fcd0 000001976232fcc8 00000118ff4a0e30 0000000000000001
00000111821ab400 0000011100000000 0000021761df6534 000001976232fb58
Krnl Code: 0000021761df6528: c020006f5ef4 larl %r2,0000021762be2310
0000021761df652e: c0e5ffbd09d5 brasl %r14,00000217615978d8
#0000021761df6534: af000000 mc 0,0
>0000021761df6538: 0707 bcr 0,%r7
0000021761df653a: 0707 bcr 0,%r7
0000021761df653c: 0707 bcr 0,%r7
0000021761df653e: 0707 bcr 0,%r7
0000021761df6540: c004004bb7ec brcl 0,000002176276d518
Call Trace:
[<0000021761df6538>] btrfs_compress_folios+0x198/0x1a0
([<0000021761df6534>] btrfs_compress_folios+0x194/0x1a0)
[<0000021761d97788>] compress_file_range+0x3b8/0x6d0
[<0000021761dcee7c>] btrfs_work_helper+0x10c/0x160
[<0000021761645760>] process_one_work+0x2b0/0x5d0
[<000002176164637e>] worker_thread+0x20e/0x3e0
[<000002176165221a>] kthread+0x15a/0x170
[<00000217615b859c>] __ret_from_fork+0x3c/0x60
[<00000217626e72d2>] ret_from_fork+0xa/0x38
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<0000021761597924>] _printk+0x4c/0x58
Kernel panic - not syncing: Fatal exception: panic_on_oops
CVSS Score
5.5
EPSS Score
0.0
Published
2025-01-19
In the Linux kernel, the following vulnerability has been resolved:
fs: relax assertions on failure to encode file handles
Encoding file handles is usually performed by a filesystem >encode_fh()
method that may fail for various reasons.
The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.
There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when ->encode_fh() fails.
Relax those assertions because they are wrong.
The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
encoding non-decodable file handles") in v6.6 as the regressing commit,
but this is not accurate.
The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.
Triggering this assertion was always possible with other filesystems and
other reasons of ->encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlayfs that is
mounted with options index=on,nfs_export=on also on kernels < v6.6.
Therefore, I am not listing the aforementioned commit as a Fixes commit.
Backport hint: this patch will have a trivial conflict applying to
v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-01-19
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix a missing return value check bug
In the smb2_send_interim_resp(), if ksmbd_alloc_work_struct()
fails to allocate a node, it returns a NULL pointer to the
in_work pointer. This can lead to an illegal memory write of
in_work->response_buf when allocate_interim_rsp_buf() attempts
to perform a kzalloc() on it.
To address this issue, incorporating a check for the return
value of ksmbd_alloc_work_struct() ensures that the function
returns immediately upon allocation failure, thereby preventing
the aforementioned illegal memory access.
CVSS Score
7.1
EPSS Score
0.001
Published
2025-01-19
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Set private->all_drm_private[i]->drm to NULL if mtk_drm_bind returns err
The pointer need to be set to NULL, otherwise KASAN complains about
use-after-free. Because in mtk_drm_bind, all private's drm are set
as follows.
private->all_drm_private[i]->drm = drm;
And drm will be released by drm_dev_put in case mtk_drm_kms_init returns
failure. However, the shutdown path still accesses the previous allocated
memory in drm_atomic_helper_shutdown.
[ 84.874820] watchdog: watchdog0: watchdog did not stop!
[ 86.512054] ==================================================================
[ 86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378
[ 86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1
[ 86.515213]
[ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55
[ 86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022
[ 86.517960] Call trace:
[ 86.518333] show_stack+0x20/0x38 (C)
[ 86.518891] dump_stack_lvl+0x90/0xd0
[ 86.519443] print_report+0xf8/0x5b0
[ 86.519985] kasan_report+0xb4/0x100
[ 86.520526] __asan_report_load8_noabort+0x20/0x30
[ 86.521240] drm_atomic_helper_shutdown+0x33c/0x378
[ 86.521966] mtk_drm_shutdown+0x54/0x80
[ 86.522546] platform_shutdown+0x64/0x90
[ 86.523137] device_shutdown+0x260/0x5b8
[ 86.523728] kernel_restart+0x78/0xf0
[ 86.524282] __do_sys_reboot+0x258/0x2f0
[ 86.524871] __arm64_sys_reboot+0x90/0xd8
[ 86.525473] invoke_syscall+0x74/0x268
[ 86.526041] el0_svc_common.constprop.0+0xb0/0x240
[ 86.526751] do_el0_svc+0x4c/0x70
[ 86.527251] el0_svc+0x4c/0xc0
[ 86.527719] el0t_64_sync_handler+0x144/0x168
[ 86.528367] el0t_64_sync+0x198/0x1a0
[ 86.528920]
[ 86.529157] The buggy address belongs to the physical page:
[ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc
[ 86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff)
[ 86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000
[ 86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000
[ 86.534511] page dumped because: kasan: bad access detected
[ 86.535323]
[ 86.535559] Memory state around the buggy address:
[ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 86.544733] ^
[ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 86.563928] ==================================================================
[ 86.571093] Disabling lock debugging due to kernel taint
[ 86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b
[ 86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f]
...
CVSS Score
7.8
EPSS Score
0.0
Published
2025-01-19
In the Linux kernel, the following vulnerability has been resolved:
nfs: Fix oops in nfs_netfs_init_request() when copying to cache
When netfslib wants to copy some data that has just been read on behalf of
nfs, it creates a new write request and calls nfs_netfs_init_request() to
initialise it, but with a NULL file pointer. This causes
nfs_file_open_context() to oops - however, we don't actually need the nfs
context as we're only going to write to the cache.
Fix this by just returning if we aren't given a file pointer and emit a
warning if the request was for something other than copy-to-cache.
Further, fix nfs_netfs_free_request() so that it doesn't try to free the
context if the pointer is NULL.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-01-19
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix enomem handling in buffered reads
If netfs_read_to_pagecache() gets an error from either ->prepare_read() or
from netfs_prepare_read_iterator(), it needs to decrement ->nr_outstanding,
cancel the subrequest and break out of the issuing loop. Currently, it
only does this for two of the cases, but there are two more that aren't
handled.
Fix this by moving the handling to a common place and jumping to it from
all four places. This is in preference to inserting a wrapper around
netfs_prepare_read_iterator() as proposed by Dmitry Antipov[1].
CVSS Score
7.1
EPSS Score
0.0
Published
2025-01-19
In the Linux kernel, the following vulnerability has been resolved:
iio: light: bh1745: fix information leak in triggered buffer
The 'scan' local struct is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace.
CVSS Score
7.1
EPSS Score
0.0
Published
2025-01-19
In the Linux kernel, the following vulnerability has been resolved:
iio: light: vcnl4035: fix information leak in triggered buffer
The 'buffer' local array is used to push data to userspace from a
triggered buffer, but it does not set an initial value for the single
data element, which is an u16 aligned to 8 bytes. That leaves at least
4 bytes uninitialized even after writing an integer value with
regmap_read().
Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace.
CVSS Score
7.1
EPSS Score
0.001
Published
2025-01-19
In the Linux kernel, the following vulnerability has been resolved:
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
The 'data' array is allocated via kmalloc() and it is used to push data
to user space from a triggered buffer, but it does not set values for
inactive channels, as it only uses iio_for_each_active_channel()
to assign new values.
Use kzalloc for the memory allocation to avoid pushing uninitialized
information to userspace.
CVSS Score
7.1
EPSS Score
0.001
Published
2025-01-19