Lucene search

K
ubuntucveUbuntu.comUB:CVE-2024-27031
HistoryMay 01, 2024 - 12:00 a.m.

CVE-2024-27031

2024-05-0100:00:00
ubuntu.com
ubuntu.com
2
linux kernel
nfs
xarray locking

6.3 Medium

AI Score

Confidence

Low

0.0004 Low

EPSS

Percentile

15.7%

In the Linux kernel, the following vulnerability has been resolved: NFS:
Fix nfs_netfs_issue_read() xarray locking for writeback interrupt The loop
inside nfs_netfs_issue_read() currently does not disable interrupts while
iterating through pages in the xarray to submit for NFS read. This is not
safe though since after taking xa_lock, another page in the mapping could
be processed for writeback inside an interrupt, and deadlock can occur. The
fix is simple and clean if we use xa_for_each_range(), which handles the
iteration with RCU while reducing code complexity. The problem is easily
reproduced with the following test: mount -o vers=3,fsc 127.0.0.1:/export
/mnt/nfs dd if=/dev/zero of=/mnt/nfs/file1.bin bs=4096 count=1 echo 3 >
/proc/sys/vm/drop_caches dd if=/mnt/nfs/file1.bin of=/dev/null umount
/mnt/nfs On the console with a lockdep-enabled kernel a message similar to
the following will be seen: ================================ WARNING:
inconsistent lock state 6.7.0-lockdbg+ #10 Not tainted
-------------------------------- inconsistent {IN-SOFTIRQ-W} ->
{SOFTIRQ-ON-W} usage. test5/1708 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff888127baa598 (&xa->xa_lock#4){+.?.}-{3:3}, at:
nfs_netfs_issue_read+0x1b2/0x4b0 [nfs] {IN-SOFTIRQ-W} state was registered
at: lock_acquire+0x144/0x380 _raw_spin_lock_irqsave+0x4e/0xa0
__folio_end_writeback+0x17e/0x5c0 folio_end_writeback+0x93/0x1b0
iomap_finish_ioend+0xeb/0x6a0 blk_update_request+0x204/0x7f0
blk_mq_end_request+0x30/0x1c0 blk_complete_reqs+0x7e/0xa0
__do_softirq+0x113/0x544 __irq_exit_rcu+0xfe/0x120 irq_exit_rcu+0xe/0x20
sysvec_call_function_single+0x6f/0x90
asm_sysvec_call_function_single+0x1a/0x20 pv_native_safe_halt+0xf/0x20
default_idle+0x9/0x20 default_idle_call+0x67/0xa0 do_idle+0x2b5/0x300
cpu_startup_entry+0x34/0x40 start_secondary+0x19d/0x1c0
secondary_startup_64_no_verify+0x18f/0x19b irq event stamp: 176891 hardirqs
last enabled at (176891): [<ffffffffa67a0be4>]
_raw_spin_unlock_irqrestore+0x44/0x60 hardirqs last disabled at (176890):
[<ffffffffa67a0899>] _raw_spin_lock_irqsave+0x79/0xa0 softirqs last enabled
at (176646): [<ffffffffa515d91e>] __irq_exit_rcu+0xfe/0x120 softirqs last
disabled at (176633): [<ffffffffa515d91e>] __irq_exit_rcu+0xfe/0x120 other
info that might help us debug this: Possible unsafe locking scenario: CPU0
---- lock(&xa->xa_lock#4); <Interrupt> lock(&xa->xa_lock#4); *** DEADLOCK*** 2 locks held by test5/1708: #0: ffff888127baa498
(&sb->s_type->i_mutex_key#22){++++}-{4:4}, at: nfs_start_io_read+0x28/0x90
[nfs] #1: ffff888127baa650 (mapping.invalidate_lock#3){.+.+}-{4:4}, at:
page_cache_ra_unbounded+0xa4/0x280 stack backtrace: CPU: 6 PID: 1708 Comm:
test5 Kdump: loaded Not tainted 6.7.0-lockdbg+ Hardware name: QEMU Standard
PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Call Trace:
dump_stack_lvl+0x5b/0x90 mark_lock+0xb3f/0xd20 __lock_acquire+0x77b/0x3360
_raw_spin_lock+0x34/0x80 nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]
netfs_begin_read+0x77f/0x980 [netfs] nfs_netfs_readahead+0x45/0x60 [nfs]
nfs_readahead+0x323/0x5a0 [nfs] read_pages+0xf3/0x5c0
page_cache_ra_unbounded+0x1c8/0x280 filemap_get_pages+0x38c/0xae0
filemap_read+0x206/0x5e0 nfs_file_read+0xb7/0x140 [nfs]
vfs_read+0x2a9/0x460 ksys_read+0xb7/0x140

6.3 Medium

AI Score

Confidence

Low

0.0004 Low

EPSS

Percentile

15.7%