deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-23142
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: detect and prevent references to a freed transport in sendmsg

sctp_sendmsg() re-uses associations and transports when possible by
doing a lookup based on the socket endpoint and the message destination
address, and then sctp_sendmsg_to_asoc() sets the selected transport in
all the message chunks to be sent.

There's a possible race condition if another thread triggers the removal
of that selected transport, for instance, by explicitly unbinding an
address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have
been set up and before the message is sent. This can happen if the send
buffer is full, during the period when the sender thread temporarily
releases the socket lock in sctp_wait_for_sndbuf().

This causes the access to the transport data in
sctp_outq_select_transport(), when the association outqueue is flushed,
to result in a use-after-free read.

This change avoids this scenario by having sctp_transport_free() signal
the freeing of the transport, tagging it as "dead". In order to do this,
the patch restores the "dead" bit in struct sctp_transport, which was
removed in
commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").

Then, in the scenario where the sender thread has released the socket
lock in sctp_wait_for_sndbuf(), the bit is checked again after
re-acquiring the socket lock to detect the deletion. This is done while
holding a reference to the transport to prevent it from being freed in
the process.

If the transport was deleted while the socket lock was relinquished,
sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the
send.

The bug was found by a private syzbot instance (see the error report [1]
and the C reproducer that triggers it [2]).
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0f7df4899299ce4662e5f95badb9dbc57cc37fa5; https://git.kernel.org/stable/c/2e5068b7e0ae0a54f6cfd03a2f80977da657f1ee; https://git.kernel.org/stable/c/3257386be6a7eb8a8bfc9cbfb746df4eb4fc70e8
CVE: CVE-2025-23144
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()

Lockdep detects the following issue on led-backlight removal:
  [  142.315935] ------------[ cut here ]------------
  [  142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80
  ...
  [  142.500725] Call trace:
  [  142.503176]  led_sysfs_enable+0x54/0x80 (P)
  [  142.507370]  led_bl_remove+0x80/0xa8 [led_bl]
  [  142.511742]  platform_remove+0x30/0x58
  [  142.515501]  device_remove+0x54/0x90
  ...

Indeed, led_sysfs_enable() has to be called with the led_access
lock held.

Hold the lock when calling led_sysfs_disable().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/11d128f7eacec276c75cf4712880a6307ca9c885; https://git.kernel.org/stable/c/1c82f5a393d8b9a5c1ea[PII_REDACTED]62098afd4b; https://git.kernel.org/stable/c/276822a00db3c1061382b41e72cafc09d6a0ec30
CVE: CVE-2025-23145
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix NULL pointer in can_accept_new_subflow

When testing valkey benchmark tool with MPTCP, the kernel panics in
'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL.

Call trace:

  mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)
  subflow_syn_recv_sock (./net/mptcp/subflow.c:854)
  tcp_check_req (./net/ipv4/tcp_minisocks.c:863)
  tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268)
  ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207)
  ip_local_deliver_finish (./net/ipv4/ip_input.c:234)
  ip_local_deliver (./net/ipv4/ip_input.c:254)
  ip_rcv_finish (./net/ipv4/ip_input.c:449)
  ...

According to the debug log, the same req received two SYN-ACK in a very
short time, very likely because the client retransmits the syn ack due
to multiple reasons.

Even if the packets are transmitted with a relevant time interval, they
can be processed by the server on different CPUs concurrently). The
'subflow_req->msk' ownership is transferred to the subflow the first,
and there will be a risk of a null pointer dereference here.

This patch fixes this issue by moving the 'subflow_req->msk' under the
`own_req == true` conditional.

Note that the !msk check in subflow_hmac_valid() can be dropped, because
the same check already exists under the own_req mpj branch where the
code has been moved to.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/443041deb5ef6a1289a99ed95015ec7442f141dc; https://git.kernel.org/stable/c/4b2649b9717678aeb097893cc49f59311a1ecab0; https://git.kernel.org/stable/c/7f9ae060ed64aef8f174c5f1ea513825b1be9af1
CVE: CVE-2025-23146
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mfd: ene-kb3930: Fix a potential NULL pointer dereference

The off_gpios could be NULL. Add missing check in the kb3930_probe().
This is similar to the issue fixed in commit b1ba8bcb2d1f
("backlight: hx8357: Fix potential NULL pointer dereference").

This was detected by our static analysis tool.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2edb5b29b197d90b4d08cd45e911c0bcf24cb895; https://git.kernel.org/stable/c/4cdf1d2a816a93fa02f7b6b5492dc7f55af2a199; https://git.kernel.org/stable/c/6dc88993ee3fa8365ff6a5d6514702f70ba6863a
CVE: CVE-2025-23147
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

i3c: Add NULL pointer check in i3c_master_queue_ibi()

The I3C master driver may receive an IBI from a target device that has not
been probed yet. In such cases, the master calls `i3c_master_queue_ibi()`
to queue an IBI work task, leading to "Unable to handle kernel read from
unreadable memory" and resulting in a kernel panic.

Typical IBI handling flow:
1. The I3C master scans target devices and probes their respective drivers.
2. The target device driver calls `i3c_device_request_ibi()` to enable IBI
   and assigns `dev->ibi = ibi`.
3. The I3C master receives an IBI from the target device and calls
   `i3c_master_queue_ibi()` to queue the target device driver’s IBI
   handler task.

However, since target device events are asynchronous to the I3C probe
sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,
leading to a kernel panic.

Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing
an uninitialized `dev->ibi`, ensuring stability.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/09359e7c[PII_REDACTED]cb5fc50220969b0a4e1058; https://git.kernel.org/stable/c/1b54faa5f47fa7c642179744aeff03f0810dc62e; https://git.kernel.org/stable/c/3ba402610843d7d15c7f3966a461deeeaff7fba4
CVE: CVE-2025-23148
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()

soc_dev_attr->revision could be NULL, thus,
a pointer check is added to prevent potential NULL pointer dereference.
This is similar to the fix in commit 3027e7b15b02
("ice: Fix some null pointer dereference issues in ice_ptp.c").

This issue is found by our static analysis tool.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4129760e462f45f14e61b10408ace61aa7c2ed30; https://git.kernel.org/stable/c/44a2572a0fdcf3e[PII_REDACTED]d579b998a8f0562; https://git.kernel.org/stable/c/475b9b45dc32eba58ab794b5d47ac689fc018398
CVE: CVE-2025-23149
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

tpm: do not start chip while suspended

Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can
lead to a spurious tpm_chip_start() call:

[35985.503771] i2c i2c-1: Transfer while suspended
[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810
[35985.503802] Modules linked in:
[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G        W          6.13.0-next-20[PII_REDACTED]5-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f
[35985.503814] Tainted: [W]=WARN
[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023
[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810
[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5
[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246
[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: [PII_REDACTED]
[35985.503836] RDX: [PII_REDACTED] RSI: ffffffffa77ab0e4 RDI: [PII_REDACTED]
[35985.503838] RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
[35985.503841] R10: [PII_REDACTED] R11:[PII_REDACTED]0313d5 R12: ffff8aa4c10f1820
[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120
[35985.503846] FS:  [PII_REDACTED](0000) GS:ffff8aa4eae00000(0000) knlGS:[PII_REDACTED]
[35985.503849] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[35985.503852] CR2: 00007fab0aaf1000 CR3: [PII_REDACTED] CR4:[PII_REDACTED]3506f0
[35985.503855] Call Trace:
[35985.503859]  <TASK>
[35985.503863]  ? __warn+0xd4/0x260
[35985.503868]  ? __i2c_transfer+0xbe/0x810
[35985.503874]  ? report_bug+0xf3/0x210
[35985.503882]  ? handle_bug+0x63/0xb0
[35985.503887]  ? exc_invalid_op+0x16/0x50
[35985.503892]  ? asm_exc_invalid_op+0x16/0x20
[35985.503904]  ? __i2c_transfer+0xbe/0x810
[35985.503913]  tpm_cr50_i2c_transfer_message+0x24/0xf0
[35985.503920]  tpm_cr50_i2c_read+0x8e/0x120
[35985.503928]  tpm_cr50_request_locality+0x75/0x170
[35985.503935]  tpm_chip_start+0x116/0x160
[35985.503942]  tpm_try_get_ops+0x57/0x90
[35985.503948]  tpm_find_get_ops+0x26/0xd0
[35985.503955]  tpm_get_random+0x2d/0x80

Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless
TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in
such a failure case.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1404dff1e11bf927b70ac25e1de97bed9742ede4; https://git.kernel.org/stable/c/17d253af4c2c8a2acf84bb55a0c2045f150b7dfd; https://git.kernel.org/stable/c/e74e2394eed90aff5c3a08c1f51f476d4de71d02
CVE: CVE-2025-23150
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix off-by-one error in do_split

Syzkaller detected a use-after-free issue in ext4_insert_dentry that was
caused by out-of-bounds access due to incorrect splitting in do_split.

BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109
Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847

CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106
 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109
 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154
 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351
 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455
 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796
 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431
 vfs_symlink+0x137/0x2e0 fs/namei.c:4615
 do_symlinkat+0x222/0x3a0 fs/namei.c:4641
 __do_sys_symlink fs/namei.c:4662 [inline]
 __se_sys_symlink fs/namei.c:4660 [inline]
 __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 </TASK>

The following loop is located right above 'if' statement.

for (i = count-1; i >= 0; i--) {
	/* is more than half of this entry in 2nd half of the block? */
	if (size + map[i].size/2 > blocksize/2)
		break;
	size += map[i].size;
	move++;
}

'i' in this case could go down to -1, in which case sum of active entries
wouldn't exceed half the block size, but previous behaviour would also do
split in half if sum would exceed at the very last block, which in case of
having too many long name files in a single block could lead to
out-of-bounds access and following use-after-free.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-193
References: https://git.kernel.org/stable/c/16d9067f00e3a7d1df7c3aa9c20d214923d27e10; https://git.kernel.org/stable/c/17df39f455f1289319d4d09e4826aa46852ffd17; https://git.kernel.org/stable/c/2883e9e74f73f9265e5f8d1aaaa89034b308e433
CVE: CVE-2025-23151
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

bus: mhi: host: Fix race between unprepare and queue_buf

A client driver may use mhi_unprepare_from_transfer() to quiesce
incoming data during the client driver's tear down. The client driver
might also be processing data at the same time, resulting in a call to
mhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs
after mhi_unprepare_from_transfer() has torn down the channel, a panic
will occur due to an invalid dereference leading to a page fault.

This occurs because mhi_gen_tre() does not verify the channel state
after locking it. Fix this by having mhi_gen_tre() confirm the channel
state is valid, or return error to avoid accessing deinitialized data.

[mani: added stable tag]
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0686a818d77a431fc3ba2fab4b46bbb04e8c9380; https://git.kernel.org/stable/c/178e5657c8fd285125cc6743a81b513bce099760; https://git.kernel.org/stable/c/3e7ecf181cbdde9753204ada3883ca1704d8702b
CVE: CVE-2025-23152
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch()

Fix a silly bug where an array was used outside of its scope.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/bd9e1a03e579a01dfa66dbaa53d0219c33cbc463; https://git.kernel.org/stable/c/d48b663f410f8b35b8ba9bd597bafaa00f53293b
CVE: CVE-2025-23153
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

arm/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch()

Fix a silly bug where an array was used outside of its scope.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3371f569223c4e8d36edbb0ba789ee5f5cb7316f; https://git.kernel.org/stable/c/d8eba735be74e74776f9f6d9c691bdb75b08b29c
CVE: CVE-2025-23154
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/net: fix io_req_post_cqe abuse by send bundle

[  114.987980][ T5313] WARNING: CPU: 6 PID: 5313 at io_uring/io_uring.c:872 io_req_post_cqe+0x12e/0x4f0
[  114.991597][ T5313] RIP: 0010:io_req_post_cqe+0x12e/0x4f0
[  115.001880][ T5313] Call Trace:
[  115.002222][ T5313]  <TASK>
[  115.007813][ T5313]  io_send+0x4fe/0x10f0
[  115.009317][ T5313]  io_issue_sqe+0x1a6/0x1740
[  115.012094][ T5313]  io_wq_submit_work+0x38b/0xed0
[  115.013223][ T5313]  io_worker_handle_work+0x62a/0x1600
[  115.013876][ T5313]  io_wq_worker+0x34f/0xdf0

As the comment states, io_req_post_cqe() should only be used by
multishot requests, i.e. REQ_F_APOLL_MULTISHOT, which bundled sends are
not. Add a flag signifying whether a request wants to post multiple
CQEs. Eventually REQ_F_APOLL_MULTISHOT should imply the new flag, but
that's left out for simplicity.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/6889ae1b4df1579bcdffef023e2ea9a982565dff; https://git.kernel.org/stable/c/7888c9fc0b2d3636f2e821ed1ad3c6920fa8e378; https://git.kernel.org/stable/c/9aa804e6b[PII_REDACTED]095fb9d335046a71550f1
CVE: CVE-2025-23155
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: Fix accessing freed irq affinity_hint

In stmmac_request_irq_multi_msi(), a pointer to the stack variable
cpu_mask is passed to irq_set_affinity_hint(). This value is stored in
irq_desc->affinity_hint, but once stmmac_request_irq_multi_msi()
returns, the pointer becomes dangling.

The affinity_hint is exposed via procfs with S_IRUGO permissions,
allowing any unprivileged process to read it. Accessing this stale
pointer can lead to:

- a kernel oops or panic if the referenced memory has been released and
  unmapped, or
- leakage of kernel data into userspace if the memory is re-used for
  other purposes.

All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are
affected.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2fbf67ddb8a0d0efc00d2df496a9843ec318d48b; https://git.kernel.org/stable/c/442312c2a90d60c7a[PII_REDACTED]fa91d9e579985; https://git.kernel.org/stable/c/960dab23f6d405740c537d095f90a4ee9ddd9285
CVE: CVE-2025-23156
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi_parser: refactor hfi packet parsing logic

words_count denotes the number of words in total payload, while data
points to payload of various property within it. When words_count
reaches last word, data can access memory beyond the total payload. This
can lead to OOB access. With this patch, the utility api for handling
individual properties now returns the size of data consumed. Accordingly
remaining bytes are calculated before parsing the payload, thereby
eliminates the OOB access possibilities.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/05b07e52a0d08239147ba[PII_REDACTED]f4fb398de; https://git.kernel.org/stable/c/0beabe9b49190a02321b02792b29fc0f0e28b51f; https://git.kernel.org/stable/c/0f9a4bab7d[PII_REDACTED]5372e[PII_REDACTED]eab2d
CVE: CVE-2025-23157
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi_parser: add check to avoid out of bound access

There is a possibility that init_codecs is invoked multiple times during
manipulated payload from video firmware. In such case, if codecs_count
can get incremented to value more than MAX_CODEC_NUM, there can be OOB
access. Reset the count so that it always starts from beginning.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/172bf5a9ef70a399bb227809db78442dc01d9e48; https://git.kernel.org/stable/c/1ad6aa1464b8a5ce5c[PII_REDACTED]1e8d216108e; https://git.kernel.org/stable/c/26bbedd06d85770581fda5d78e78539bb088fad1
CVE: CVE-2025-23158
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi: add check to handle incorrect queue size

qsize represents size of shared queued between driver and video
firmware. Firmware can modify this value to an invalid large value. In
such situation, empty_space will be bigger than the space actually
available. Since new_wr_idx is not checked, so the following code will
result in an OOB write.
...
qsize = qhdr->q_size

if (wr_idx >= rd_idx)
 empty_space = qsize - (wr_idx - rd_idx)
....
if (new_wr_idx < qsize) {
 memcpy(wr_ptr, packet, dwords << 2) --> OOB write

Add check to ensure qsize is within the allocated size while
reading and writing packets into the queue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/101a86619aab42bb61f2253bbf720121022eab86; https://git.kernel.org/stable/c/1b86c1917e16bafbbb08ab90baaff533aa36c62d; https://git.kernel.org/stable/c/32af5c1fdb9bc274f52ee0472d3b060b18e4aab4
CVE: CVE-2025-23159
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

media: venus: hfi: add a check to handle OOB in sfr region

sfr->buf_size is in shared memory and can be modified by malicious user.
OOB write is possible when the size is made higher than actual sfr data
buffer. Cap the size to allocated size for such cases.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/1b8fb257234e7d2d4b3f48af07c5aa5e11c71634; https://git.kernel.org/stable/c/4dd109038d513b92d4d33524ffc89ba32e02ba48; https://git.kernel.org/stable/c/4e95233af57715d81830fe82b408c633edff59f4
CVE: CVE-2025-23160
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization

On Mediatek devices with a system companion processor (SCP) the mtk_scp
structure has to be removed explicitly to avoid a resource leak.
Free the structure in case the allocation of the firmware structure fails
during the firmware initialization.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4936cd5817af35d23e4d283f48fa59a18ef481e4; https://git.kernel.org/stable/c/69dd5bbdd79c65445bb17c3c53510783bc1d756c; https://git.kernel.org/stable/c/9f009fa823c54ca0857c81f7525ea5a5d32de29c
CVE: CVE-2025-23161
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type

The access to the PCI config space via pci_ops::read and pci_ops::write is
a low-level hardware access. The functions can be accessed with disabled
interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this
purpose.

A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be
acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in
the same context as the pci_lock.

Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with
interrupts disabled.

This was reported as:

  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
  Call Trace:
   rt_spin_lock+0x4e/0x130
   vmd_pci_read+0x8d/0x100 [vmd]
   pci_user_read_config_byte+0x6f/0xe0
   pci_read_config+0xfe/0x290
   sysfs_kf_bin_read+0x68/0x90

[bigeasy: reword commit message]
Tested-off-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com>
[kwilczynski: commit log]
[bhelgaas: add back report info from
https://lore.kernel.org/lkml/[PII_REDACTED]5951.83062-1-ryotkkr98@gmail.com/]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/13e5148f70e81991acbe0bab5b1b50ba699116e7; https://git.kernel.org/stable/c/18056a48669a040bef491e63b25896561ee14d90; https://git.kernel.org/stable/c/20d0a9062c031068fa39f725a32f182b709b5525