Security Vulnerabilities - CVEs Published In February 2025
In the Linux kernel, the following vulnerability has been resolved:
iio: accel: mma8452: use the correct logic to get mma8452_data
The original logic to get mma8452_data is wrong, the *dev point to
the device belong to iio_dev. we can't use this dev to find the
correct i2c_client. The original logic happen to work because it
finally use dev->driver_data to get iio_dev. Here use the API
to_i2c_client() is wrong and make reader confuse. To correct the
logic, it should be like this
struct mma8452_data *data = iio_priv(dev_get_drvdata(dev));
But after commit 8b7651f25962 ("iio: iio_device_alloc(): Remove
unnecessary self drvdata"), the upper logic also can't work.
When try to show the avialable scale in userspace, will meet kernel
dump, kernel handle NULL pointer dereference.
So use dev_to_iio_dev() to correct the logic.
Dual fixes tags as the second reflects when the bug was exposed, whilst
the first reflects when the original bug was introduced.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
tpm: use try_get_ops() in tpm-space.c
As part of the series conversion to remove nested TPM operations:
https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/
exposure of the chip->tpm_mutex was removed from much of the upper
level code. In this conversion, tpm2_del_space() was missed. This
didn't matter much because it's usually called closely after a
converted operation, so there's only a very tiny race window where the
chip can be removed before the space flushing is done which causes a
NULL deref on the mutex. However, there are reports of this window
being hit in practice, so fix this by converting tpm2_del_space() to
use tpm_try_get_ops(), which performs all the teardown checks before
acquring the mutex.
CVSS Score
4.7
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
tpm: fix reference counting for struct tpm_chip
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm.
2. Remove module tpm_tis_spi.
3. Write a TPM command to the file descriptor opened at step 1.
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4
refcount_t: addition on 0; use-after-free.
Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac
sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4
brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes
raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm
snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]
CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2
Hardware name: BCM2711
[<c0410c3c>] (unwind_backtrace) from [<c040b580>] (show_stack+0x10/0x14)
[<c040b580>] (show_stack) from [<c1092174>] (dump_stack+0xc4/0xd8)
[<c1092174>] (dump_stack) from [<c0445a30>] (__warn+0x104/0x108)
[<c0445a30>] (__warn) from [<c0445aa8>] (warn_slowpath_fmt+0x74/0xb8)
[<c0445aa8>] (warn_slowpath_fmt) from [<c08435d0>] (kobject_get+0xa0/0xa4)
[<c08435d0>] (kobject_get) from [<bf0a715c>] (tpm_try_get_ops+0x14/0x54 [tpm])
[<bf0a715c>] (tpm_try_get_ops [tpm]) from [<bf0a7d6c>] (tpm_common_write+0x38/0x60 [tpm])
[<bf0a7d6c>] (tpm_common_write [tpm]) from [<c05a7ac0>] (vfs_write+0xc4/0x3c0)
[<c05a7ac0>] (vfs_write) from [<c05a7ee4>] (ksys_write+0x58/0xcc)
[<c05a7ee4>] (ksys_write) from [<c04001a0>] (ret_fast_syscall+0x0/0x4c)
Exception stack(0xc226bfa8 to 0xc226bff0)
bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000
bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684
bfe0: 0000006c beafe648 0001056c b6eb6944
---[ end trace d4b8409def9b8b1f ]---
The reason for this warning is the attempt to get the chip->dev reference
in tpm_common_write() although the reference counter is already zero.
Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") the
extra reference used to prevent a premature zero counter is never taken,
because the required TPM_CHIP_FLAG_TPM2 flag is never set.
Fix this by moving the TPM 2 character device handling from
tpm_chip_alloc() to tpm_add_char_device() which is called at a later point
in time when the flag has been set in case of TPM2.
Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm<n>")
already introduced function tpm_devs_release() to release the extra
reference but did not implement the required put on chip->devs that results
in the call of this function.
Fix this by putting chip->devs in tpm_chip_unregister().
Finally move the new implementation for the TPM 2 handling into a new
function to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in the
good case and error cases.
CVSS Score
7.8
EPSS Score
0.001
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix races among concurrent prealloc proc writes
We have no protection against concurrent PCM buffer preallocation
changes via proc files, and it may potentially lead to UAF or some
weird problem. This patch applies the PCM open_mutex to the proc
write operation for avoiding the racy proc writes and the PCM stream
open (and further operations).
CVSS Score
7.8
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
uaccess: fix integer overflow on access_ok()
Three architectures check the end of a user access against the
address limit without taking a possible overflow into account.
Passing a negative length or another overflow in here returns
success when it should not.
Use the most common correct implementation here, which optimizes
for a constant 'size' argument, and turns the common case into a
single comparison.
CVSS Score
7.1
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
mac80211: fix potential double free on mesh join
While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving
mesh") fixed a memory leak on mesh leave / teardown it introduced a
potential memory corruption caused by a double free when rejoining the
mesh:
ieee80211_leave_mesh()
-> kfree(sdata->u.mesh.ie);
...
ieee80211_join_mesh()
-> copy_mesh_setup()
-> old_ie = ifmsh->ie;
-> kfree(old_ie);
This double free / kernel panics can be reproduced by using wpa_supplicant
with an encrypted mesh (if set up without encryption via "iw" then
ifmsh->ie is always NULL, which avoids this issue). And then calling:
$ iw dev mesh0 mesh leave
$ iw dev mesh0 mesh join my-mesh
Note that typically these commands are not used / working when using
wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going
through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join
where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of
default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids
the memory corruption, too.
The issue was first observed in an application which was not using
wpa_supplicant but "Senf" instead, which implements its own calls to
nl80211.
Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh
join function and leaving it solely up to the mesh leave to free the
mesh IE.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix races among concurrent hw_params and hw_free calls
Currently we have neither proper check nor protection against the
concurrent calls of PCM hw_params and hw_free ioctls, which may result
in a UAF. Since the existing PCM stream lock can't be used for
protecting the whole ioctl operations, we need a new mutex to protect
those racy calls.
This patch introduced a new mutex, runtime->buffer_mutex, and applies
it to both hw_params and hw_free ioctl code paths. Along with it, the
both functions are slightly modified (the mmap_count check is moved
into the state-check block) for code simplicity.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent bad output lengths in smb2_ioctl_query_info()
When calling smb2_ioctl_query_info() with
smb_query_info::flags=PASSTHRU_FSCTL and
smb_query_info::output_buffer_length=0, the following would return
0x10
buffer = memdup_user(arg + sizeof(struct smb_query_info),
qi.output_buffer_length);
if (IS_ERR(buffer)) {
kfree(vars);
return PTR_ERR(buffer);
}
rather than a valid pointer thus making IS_ERR() check fail. This
would then cause a NULL ptr deference in @buffer when accessing it
later in smb2_ioctl_query_ioctl(). While at it, prevent having a
@buffer smaller than 8 bytes to correctly handle SMB2_SET_INFO
FileEndOfFileInformation requests when
smb_query_info::flags=PASSTHRU_SET_INFO.
Here is a small C reproducer which triggers a NULL ptr in @buffer when
passing an invalid smb_query_info::flags
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#define die(s) perror(s), exit(1)
#define QUERY_INFO 0xc018cf07
int main(int argc, char *argv[])
{
int fd;
if (argc < 2)
exit(1);
fd = open(argv[1], O_RDONLY);
if (fd == -1)
die("open");
if (ioctl(fd, QUERY_INFO, (uint32_t[]) { 0, 0, 0, 4, 0, 0}) == -1)
die("ioctl");
close(fd);
return 0;
}
mount.cifs //srv/share /mnt -o ...
gcc repro.c && ./a.out /mnt/f0
[ 114.138620] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
[ 114.139310] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 114.139775] CPU: 2 PID: 995 Comm: a.out Not tainted 5.17.0-rc8 #1
[ 114.140148] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
[ 114.140818] RIP: 0010:smb2_ioctl_query_info+0x206/0x410 [cifs]
[ 114.141221] Code: 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 c8 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 7b 28 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9c 01 00 00 49 8b 3f e8 58 02 fb ff 48 8b 14 24
[ 114.142348] RSP: 0018:ffffc90000b47b00 EFLAGS: 00010256
[ 114.142692] RAX: dffffc0000000000 RBX: ffff888115503200 RCX: ffffffffa020580d
[ 114.143119] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffa043a380
[ 114.143544] RBP: ffff888115503278 R08: 0000000000000001 R09: 0000000000000003
[ 114.143983] R10: fffffbfff4087470 R11: 0000000000000001 R12: ffff888115503288
[ 114.144424] R13: 00000000ffffffea R14: ffff888115503228 R15: 0000000000000000
[ 114.144852] FS: 00007f7aeabdf740(0000) GS:ffff888151600000(0000) knlGS:0000000000000000
[ 114.145338] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 114.145692] CR2: 00007f7aeacfdf5e CR3: 000000012000e000 CR4: 0000000000350ee0
[ 114.146131] Call Trace:
[ 114.146291] <TASK>
[ 114.146432] ? smb2_query_reparse_tag+0x890/0x890 [cifs]
[ 114.146800] ? cifs_mapchar+0x460/0x460 [cifs]
[ 114.147121] ? rcu_read_lock_sched_held+0x3f/0x70
[ 114.147412] ? cifs_strndup_to_utf16+0x15b/0x250 [cifs]
[ 114.147775] ? dentry_path_raw+0xa6/0xf0
[ 114.148024] ? cifs_convert_path_to_utf16+0x198/0x220 [cifs]
[ 114.148413] ? smb2_check_message+0x1080/0x1080 [cifs]
[ 114.148766] ? rcu_read_lock_sched_held+0x3f/0x70
[ 114.149065] cifs_ioctl+0x1577/0x3320 [cifs]
[ 114.149371] ? lock_downgrade+0x6f0/0x6f0
[ 114.149631] ? cifs_readdir+0x2e60/0x2e60 [cifs]
[ 114.149956] ? rcu_read_lock_sched_held+0x3f/0x70
[ 114.150250] ? __rseq_handle_notify_resume+0x80b/0xbe0
[ 114.150562] ? __up_read+0x192/0x710
[ 114.150791] ? __ia32_sys_rseq+0xf0/0xf0
[ 114.151025] ? __x64_sys_openat+0x11f/0x1d0
[ 114.151296] __x64_sys_ioctl+0x127/0x190
[ 114.151549] do_syscall_64+0x3b/0x90
[ 114.151768] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 114.152079] RIP: 0033:0x7f7aead043df
[ 114.152306] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24
---truncated---
CVSS Score
5.5
EPSS Score
0.001
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
syzbot caught a potential deadlock between the PCM
runtime->buffer_mutex and the mm->mmap_lock. It was brought by the
recent fix to cover the racy read/write and other ioctls, and in that
commit, I overlooked a (hopefully only) corner case that may take the
revert lock, namely, the OSS mmap. The OSS mmap operation
exceptionally allows to re-configure the parameters inside the OSS
mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the
copy_from/to_user calls at read/write operations also take the
mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.
A similar problem was already seen in the past and we fixed it with a
refcount (in commit b248371628aa). The former fix covered only the
call paths with OSS read/write and OSS ioctls, while we need to cover
the concurrent access via both ALSA and OSS APIs now.
This patch addresses the problem above by replacing the buffer_mutex
lock in the read/write operations with a refcount similar as we've
used for OSS. The new field, runtime->buffer_accessing, keeps the
number of concurrent read/write operations. Unlike the former
buffer_mutex protection, this protects only around the
copy_from/to_user() calls; the other codes are basically protected by
the PCM stream lock. The refcount can be a negative, meaning blocked
by the ioctls. If a negative value is seen, the read/write aborts
with -EBUSY. In the ioctl side, OTOH, they check this refcount, too,
and set to a negative value for blocking unless it's already being
accessed.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26
In the Linux kernel, the following vulnerability has been resolved:
rtc: pl031: fix rtc features null pointer dereference
When there is no interrupt line, rtc alarm feature is disabled.
The clearing of the alarm feature bit was being done prior to allocations
of ldata->rtc device, resulting in a null pointer dereference.
Clear RTC_FEATURE_ALARM after the rtc device is allocated.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-02-26