cve/published/2024/CVE-2024-43891.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2024-43891: tracing: Have format file honor EVENT_FILE_FL_FREED

 Description
 ===========

 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 data flag "EVENT_FILE_FL_FREED", so it would access the
 event that the file meta data pointed to after the event was freed.

 After inspection, there are other locations that were found to not check
 the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a
 new helper function: event_file_file() that will make sure that the
 event_mutex is held, and will return NULL if the trace_event_file has the
 EVENT_FILE_FL_FREED flag set. Have the first reference of the struct file
 pointer use event_file_file() and check for NULL. Later uses can still use
 the event_file_data() helper function if the event_mutex is still held and
 was not released since the event_file_file() call.

 The Linux kernel CVE team has assigned CVE-2024-43891 to this issue.


 Affected and fixed versions
 ===========================

 	Issue introduced in 6.6.33 with commit 14aa4f3efc6e784847e8c8543a7ef34ec9bdbb01 and fixed in 6.6.49 with commit 4ed03758ddf0b19d69eed69386d65a92d0091e0c
 	Issue introduced in 6.9 with commit b63db58e2fa5d6963db9c45df88e60060f0ff35f and fixed in 6.10.5 with commit 531dc6780d94245af037c25c2371c8caf652f0f9
 	Issue introduced in 6.9 with commit b63db58e2fa5d6963db9c45df88e60060f0ff35f and fixed in 6.11 with commit b1560408692cd0ab0370cfbe9deb03ce97ab3f6d

 Please see https://www.kernel.org for a full list of currently supported
 kernel versions by the kernel community.

 Unaffected versions might change over time as fixes are backported to
 older supported kernel versions.  The official CVE entry at
 	https://cve.org/CVERecord/?id=CVE-2024-43891
 will be updated if fixes are backported, please check that for the most
 up to date information about this issue.


 Affected files
 ==============

 The file(s) affected by this issue are:
 	kernel/trace/trace.h
 	kernel/trace/trace_events.c
 	kernel/trace/trace_events_hist.c
 	kernel/trace/trace_events_inject.c
 	kernel/trace/trace_events_trigger.c


 Mitigation
 ==========

 The Linux kernel CVE team recommends that you update to the latest
 stable kernel version for this, and many other bugfixes.  Individual
 changes are never tested alone, but rather are part of a larger kernel
 release.  Cherry-picking individual commits is not recommended or
 supported by the Linux kernel community at all.  If however, updating to
 the latest release is impossible, the individual changes to resolve this
 issue can be found at these commits:
 	https://git.kernel.org/stable/c/4ed03758ddf0b19d69eed69386d65a92d0091e0c
 	https://git.kernel.org/stable/c/531dc6780d94245af037c25c2371c8caf652f0f9
 	https://git.kernel.org/stable/c/b1560408692cd0ab0370cfbe9deb03ce97ab3f6d
	From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2024-43891: tracing: Have format file honor EVENT_FILE_FL_FREED

	Description
	===========

	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 data flag "EVENT_FILE_FL_FREED", so it would access the
	event that the file meta data pointed to after the event was freed.

	After inspection, there are other locations that were found to not check
	the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a
	new helper function: event_file_file() that will make sure that the
	event_mutex is held, and will return NULL if the trace_event_file has the
	EVENT_FILE_FL_FREED flag set. Have the first reference of the struct file
	pointer use event_file_file() and check for NULL. Later uses can still use
	the event_file_data() helper function if the event_mutex is still held and
	was not released since the event_file_file() call.

	The Linux kernel CVE team has assigned CVE-2024-43891 to this issue.


	Affected and fixed versions
	===========================

	Issue introduced in 6.6.33 with commit 14aa4f3efc6e784847e8c8543a7ef34ec9bdbb01 and fixed in 6.6.49 with commit 4ed03758ddf0b19d69eed69386d65a92d0091e0c
	Issue introduced in 6.9 with commit b63db58e2fa5d6963db9c45df88e60060f0ff35f and fixed in 6.10.5 with commit 531dc6780d94245af037c25c2371c8caf652f0f9
	Issue introduced in 6.9 with commit b63db58e2fa5d6963db9c45df88e60060f0ff35f and fixed in 6.11 with commit b1560408692cd0ab0370cfbe9deb03ce97ab3f6d

	Please see https://www.kernel.org for a full list of currently supported
	kernel versions by the kernel community.

	Unaffected versions might change over time as fixes are backported to
	older supported kernel versions. The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-43891
	will be updated if fixes are backported, please check that for the most
	up to date information about this issue.


	Affected files
	==============

	The file(s) affected by this issue are:
	kernel/trace/trace.h
	kernel/trace/trace_events.c
	kernel/trace/trace_events_hist.c
	kernel/trace/trace_events_inject.c
	kernel/trace/trace_events_trigger.c


	Mitigation
	==========

	The Linux kernel CVE team recommends that you update to the latest
	stable kernel version for this, and many other bugfixes. Individual
	changes are never tested alone, but rather are part of a larger kernel
	release. Cherry-picking individual commits is not recommended or
	supported by the Linux kernel community at all. If however, updating to
	the latest release is impossible, the individual changes to resolve this
	issue can be found at these commits:
	https://git.kernel.org/stable/c/4ed03758ddf0b19d69eed69386d65a92d0091e0c
	https://git.kernel.org/stable/c/531dc6780d94245af037c25c2371c8caf652f0f9
	https://git.kernel.org/stable/c/b1560408692cd0ab0370cfbe9deb03ce97ab3f6d