CVE-2025-37970

iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo

5.5 MediumFix available

In the Linux kernel, the following vulnerability has been resolved:

iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo

Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.

Attack profile

How easy it is to exploit

Attack vector: Local
Complexity: Low
Privileges needed: Low
User interaction: None

What an attacker can affect

Confidentiality: None
Integrity: None
Availability: High

Exploit likelihood

0.18%Up 0.2 points since May 21, 2025

What each source reports

NVD Score used 5.5

In the Linux kernel, the following vulnerability has been resolved:

iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo

Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.

Record: CVE-2025-37970
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness: CWE-667
Updated: 2026-11-02

CVE List No score

iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo

In the Linux kernel, the following vulnerability has been resolved:

iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo

Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.

Record: CVE-2025-37970
Updated: 2026-11-02

EUVDEUVD-2025-15857 No score

In the Linux kernel, the following vulnerability has been resolved:

iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo

Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.

Record: EUVD-2025-15857
Updated: 2026-11-02

GitHub AdvisoriesGHSA-7xj4-qj2w-mpf9 5.5

In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix...

In the Linux kernel, the following vulnerability has been resolved:

iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo

Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.

Record: GHSA-7xj4-qj2w-mpf9
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness: CWE-667
Updated: 2026-11-02

OSVBELL-CVE-2025-37970 5.5

Record: BELL-CVE-2025-37970
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

OSVDEBIAN-CVE-2025-37970 5.5

In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.

Record: DEBIAN-CVE-2025-37970
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

Show 45 moreShow less

OSVOESA-2025-1572 8.4

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode

ath11k_hal_srng_* should be used with srng->lock to protect srng data.

For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock.

So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319

So add srng->lock for them to avoid such warnings.

Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx().

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-58096)

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix RCU stall while reaping monitor destination ring

While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id.

However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash.

kernel log: ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed

Fix this by skipping the problematic buf_id and reaping the next entry, replacing the break with the next MSDU processing.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-58097)

In the Linux kernel, the following vulnerability has been resolved:

wifi: nl80211: reject cooked mode if it is set along with other flags

It is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVE flags simultaneously on the same monitor interface from the userspace. This causes a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bit set because the monitor interface is in the cooked state and it takes precedence over all other states. When the interface is then being deleted the kernel calls WARN_ONCE() from check_sdata_in_driver() because of missing that bit.

Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along with other flags.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-21909)

In the Linux kernel, the following vulnerability has been resolved:

gpio: rcar: Use raw_spinlock to protect register access

Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access.

[    4.239592] =============================
[    4.239595] [ BUG: Invalid wait context ]
[    4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted
[    4.239603] -----------------------------
[    4.239606] kworker/u8:5/76 is trying to lock:
[    4.239609] ffff0000091898a0 (&amp;p-&gt;lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164
[    4.239641] other info that might help us debug this:

…

Record: OESA-2025-1572
CVSS 3.1: 8.4 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-1573 8.4