CVE-2024-43891

published 2024-08-26

CVE-2024-43891: In the Linux kernel, the following vulnerability has been resolved: tracing: Have format file honor EVENT_FILE_FL_FREED When eventfs was introduced, special…

Priority P4 19 medium 4.7 CVSS 3.1

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

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

tracing: Have format file honor EVENT_FILE_FL_FREED

When eventfs was introduced, special care had to be done to coordinate the
freeing of the file meta data with the files that are exposed to user
space. The file meta data would have a ref count that is set when the file
is created and would be decremented and freed after the last user that
opened the file closed it. When the file meta data was to be freed, it
would set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed,
and any new references made (like new opens or reads) would fail as it is
marked freed. This allowed other meta data to be freed after this flag was
set (under the event_mutex).

All the files that were dynamically created in the events directory had a
pointer to the file meta data and would call event_release() when the last
reference to the user space file was closed. This would be the time that it
is safe to free the file meta data.

A shortcut was made for the "format" file. It's i_private would point to
the "call" entry directly and not point to the file's meta data. This is
because all format files are the same for the same "call", so it was
thought there was no reason to differentiate them. The other files
maintain state (like the "enable", "trigger", etc). But this meant if the
file were to disappear, the "format" file would be unaware of it.

This caused a race that could be trigger via the user_events test (that
would create dynamic events and free them), and running a loop that would
read the user_events format files:

In one console run:

# cd tools/testing/selftests/user_events
# while true; do ./ftrace_test; done

And in another console run:

# cd /sys/kernel/tracing/
# while true; do cat events/user_events/__test_event/format; done 2>/dev/null

With KASAN memory checking, it would trigger a use-after-free bug report
(which was a real bug). This was because the format file was not checking
the file's meta

Affected

17 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 6.10.6-1 (forky)	linux 6.10.6-1 (forky)
linux	linux	—	—
linux	linux	>= 14aa4f3efc6e784847e8c8543a7ef34ec9bdbb01 < 4ed03758ddf0b19d69eed69386d65a92d0091e0c	4ed03758ddf0b19d69eed69386d65a92d0091e0c
linux	linux	>= 6.6.33 < 6.6.49	6.6.49
linux	linux	>= b63db58e2fa5d6963db9c45df88e60060f0ff35f < 531dc6780d94245af037c25c2371c8caf652f0f9	531dc6780d94245af037c25c2371c8caf652f0f9
linux	linux	>= b63db58e2fa5d6963db9c45df88e60060f0ff35f < b1560408692cd0ab0370cfbe9deb03ce97ab3f6d	b1560408692cd0ab0370cfbe9deb03ce97ab3f6d
linux	linux_kernel	—	—
linux	linux_kernel	—	—
linux	linux_kernel	>= 0 < 6.10.6-1	6.10.6-1
linux	linux_kernel	>= 0 < 6.10.6-1	6.10.6-1
linux	linux_kernel	>= 0 < 6.8.0-50.51	6.8.0-50.51
linux	linux_kernel	>= 6.6.33 < 6.6.49	6.6.49
linux	linux_kernel	>= 6.9 < 6.10.5	6.10.5
msrc	azl3_kernel_6.6.47.1-1_on_azure_linux_3.0	—	—
msrc	azl3_kernel_6.6.51.1-1_on_azure_linux_3.0	—	—
msrc	azure_linux_3.0_arm	—	—
msrc	azure_linux_3.0_x64	—	—

CVSS provenance

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

osv 5.5 MEDIUM

vendor_ubuntu 5.5 MEDIUM

vendor_debian 4.7 LOW

vendor_msrc 4.7 MEDIUM

vendor_redhat 4.7 MEDIUM

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-416