CVE-2024-47741

published 2024-10-21

CVE-2024-47741: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing…

Priority P4 31 high 7 CVSS 3.1

AV L AC H PR L UI N S U C H I H A H

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

btrfs: fix race setting file private on concurrent lseek using same fd

When doing concurrent lseek(2) system calls against the same file
descriptor, using multiple threads belonging to the same process, we have
a short time window where a race happens and can result in a memory leak.

The race happens like this:

1) A program opens a file descriptor for a file and then spawns two
threads (with the pthreads library for example), lets call them
task A and task B;

2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at
file.c:find_desired_extent() while holding a read lock on the inode;

3) At the start of find_desired_extent(), it extracts the file's
private_data pointer into a local variable named 'private', which has
a value of NULL;

4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode
in shared mode and enters file.c:find_desired_extent(), where it also
extracts file->private_data into its local variable 'private', which
has a NULL value;

5) Because it saw a NULL file private, task A allocates a private
structure and assigns to the file structure;

6) Task B also saw a NULL file private so it also allocates its own file
private and then assigns it to the same file structure, since both
tasks are using the same file descriptor.

At this point we leak the private structure allocated by task A.

Besides the memory leak, there's also the detail that both tasks end up
using the same cached state record in the private structure (struct
btrfs_file_private::llseek_cached_state), which can result in a
use-after-free problem since one task can free it while the other is
still using it (only one task took a reference count on it). Also, sharing
the cached state is not a good idea since it could result in incorrect
results in the future - right now it should not be a problem because it
end ups being used only in extent-io-tree.c:count_range_bits() where we do
range validation b

Affected

17 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 6.11.2-1 (forky)	linux 6.11.2-1 (forky)
linux	linux	—	—
linux	linux	>= 3c32c7212f1639471ec0197ff1179b8ef2e0f3d3 < f56a6d9c267ec7fa558ede7755551c047b1034cd	f56a6d9c267ec7fa558ede7755551c047b1034cd
linux	linux	>= 3c32c7212f1639471ec0197ff1179b8ef2e0f3d3 < a412ca489ac27b9d0e603499315b7139c948130d	a412ca489ac27b9d0e603499315b7139c948130d
linux	linux	>= 3c32c7212f1639471ec0197ff1179b8ef2e0f3d3 < 33d1310d4496e904123dab9c28b2d8d2c1800f97	33d1310d4496e904123dab9c28b2d8d2c1800f97
linux	linux	>= 3c32c7212f1639471ec0197ff1179b8ef2e0f3d3 < 7ee85f5515e86a4e2a2f51969795920733912bad	7ee85f5515e86a4e2a2f51969795920733912bad
linux	linux_kernel	>= 0 < 6.11.2-1	6.11.2-1
linux	linux_kernel	>= 0 < 6.11.2-1	6.11.2-1
linux	linux_kernel	>= 0 < 6.8.0-54.56	6.8.0-54.56
linux	linux_kernel	>= 0 < 6.11.0-18.18	6.11.0-18.18
linux	linux_kernel	>= 6.11 < 6.11.2	6.11.2
linux	linux_kernel	>= 6.2 < 6.6.54	6.6.54
linux	linux_kernel	>= 6.7 < 6.10.13	6.10.13
msrc	azl3_kernel_6.6.51.1-5_on_azure_linux_3.0	—	—
msrc	azl3_kernel_6.6.56.1-5_on_azure_linux_3.0	—	—
msrc	azure_linux_3.0_arm	—	—
msrc	azure_linux_3.0_x64	—	—

CVSS provenance

nvd v3.1 7.0 HIGH CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

osv 8.8 HIGH

vendor_ubuntu 8.8 HIGH

vendor_debian 7.0 LOW

vendor_msrc 7.0 HIGH

vendor_redhat 7.0 HIGH

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.

CWE-362