Bug 1225836 (CVE-2024-36963) - VUL-0: CVE-2024-36963: kernel: tracefs: Reset permissions on remount if permissions are options
Summary: VUL-0: CVE-2024-36963: kernel: tracefs: Reset permissions on remount if permi...
Status: RESOLVED INVALID
Alias: CVE-2024-36963
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P5 - None : Minor
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/408448/
Whiteboard: CVSSv3.1:SUSE:CVE-2024-36963:3.3:(AV:...
Keywords:
Depends on:
Blocks:
 
Reported: 2024-06-03 12:35 UTC by SMASH SMASH
Modified: 2024-06-03 12:39 UTC (History)
1 user (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SMASH SMASH 2024-06-03 12:35:10 UTC
In the Linux kernel, the following vulnerability has been resolved:

tracefs: Reset permissions on remount if permissions are options

There's an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode's permission if they were never set by the user. If the user
sets the permissions, then a flag is set and the permissions are saved via
the inode (for tracefs files) or an internal attribute field (for
eventfs).

But if a remount happens that specify the permissions, all the files that
were not changed by the user gets updated, but the ones that were are not.
If the user were to remount the file system with a given permission, then
all files and directories within that file system should be updated.

This can cause security issues if a file's permission was updated but the
admin forgot about it. They could incorrectly think that remounting with
permissions set would update all files, but miss some.

For example:

 # cd /sys/kernel/tracing
 # chgrp 1002 current_tracer
 # ls -l
[..]
 -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb
 -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb
 -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb
 -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer
 -rw-r-----  1 root root 0 May  1 21:25 dynamic_events
 -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info
 -r--r-----  1 root root 0 May  1 21:25 enabled_functions

Where current_tracer now has group "lkp".

 # mount -o remount,gid=1001 .
 # ls -l
 -rw-r-----  1 root tracing 0 May  1 21:25 buffer_size_kb
 -rw-r-----  1 root tracing 0 May  1 21:25 buffer_subbuf_size_kb
 -r--r-----  1 root tracing 0 May  1 21:25 buffer_total_size_kb
 -rw-r-----  1 root lkp     0 May  1 21:25 current_tracer
 -rw-r-----  1 root tracing 0 May  1 21:25 dynamic_events
 -r--r-----  1 root tracing 0 May  1 21:25 dyn_ftrace_total_info
 -r--r-----  1 root tracing 0 May  1 21:25 enabled_functions

Everything changed but the "current_tracer".

Add a new link list that keeps track of all the tracefs_inodes which has
the permission flags that tell if the file/dir should use the root inode's
permission or not. Then on remount, clear all the flags so that the
default behavior of using the root inode's permission is done for all
files and directories.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-36963
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-36963.mbox
https://git.kernel.org/stable/c/5f91fc82794d4a6e41cdcd02d00baa377d94ca78
https://git.kernel.org/stable/c/414fb08628143203d29ccd0264b5a83fb9523c03
https://git.kernel.org/stable/c/baa23a8d4360d981a49913841a726edede5cdd54
https://www.cve.org/CVERecord?id=CVE-2024-36963
Comment 1 Robert Frohl 2024-06-03 12:39:33 UTC
not relevant for any kernels we have