CVE-2024-43891

Severity CVSS v4.0:
Pending analysis
Type:
CWE-416 Use After Free
Publication date:
26/08/2024
Last modified:
05/09/2024

Description

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Have format file honor EVENT_FILE_FL_FREED<br /> <br /> When eventfs was introduced, special care had to be done to coordinate the<br /> freeing of the file meta data with the files that are exposed to user<br /> space. The file meta data would have a ref count that is set when the file<br /> is created and would be decremented and freed after the last user that<br /> opened the file closed it. When the file meta data was to be freed, it<br /> would set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed,<br /> and any new references made (like new opens or reads) would fail as it is<br /> marked freed. This allowed other meta data to be freed after this flag was<br /> set (under the event_mutex).<br /> <br /> All the files that were dynamically created in the events directory had a<br /> pointer to the file meta data and would call event_release() when the last<br /> reference to the user space file was closed. This would be the time that it<br /> is safe to free the file meta data.<br /> <br /> A shortcut was made for the "format" file. It&amp;#39;s i_private would point to<br /> the "call" entry directly and not point to the file&amp;#39;s meta data. This is<br /> because all format files are the same for the same "call", so it was<br /> thought there was no reason to differentiate them. The other files<br /> maintain state (like the "enable", "trigger", etc). But this meant if the<br /> file were to disappear, the "format" file would be unaware of it.<br /> <br /> This caused a race that could be trigger via the user_events test (that<br /> would create dynamic events and free them), and running a loop that would<br /> read the user_events format files:<br /> <br /> In one console run:<br /> <br /> # cd tools/testing/selftests/user_events<br /> # while true; do ./ftrace_test; done<br /> <br /> And in another console run:<br /> <br /> # cd /sys/kernel/tracing/<br /> # while true; do cat events/user_events/__test_event/format; done 2&gt;/dev/null<br /> <br /> With KASAN memory checking, it would trigger a use-after-free bug report<br /> (which was a real bug). This was because the format file was not checking<br /> the file&amp;#39;s meta data flag "EVENT_FILE_FL_FREED", so it would access the<br /> event that the file meta data pointed to after the event was freed.<br /> <br /> After inspection, there are other locations that were found to not check<br /> the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a<br /> new helper function: event_file_file() that will make sure that the<br /> event_mutex is held, and will return NULL if the trace_event_file has the<br /> EVENT_FILE_FL_FREED flag set. Have the first reference of the struct file<br /> pointer use event_file_file() and check for NULL. Later uses can still use<br /> the event_file_data() helper function if the event_mutex is still held and<br /> was not released since the event_file_file() call.

Vulnerable products and versions

CPE From Up to
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 6.6.33 (including) 6.6.49 (excluding)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 6.9 (including) 6.10.5 (excluding)
cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:*