ghsa-2r24-5j8r-cf83
Vulnerability from github
Published
2024-06-03 09:30
Modified
2024-06-03 09:30
Details

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.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-36963"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-03T08:15:09Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracefs: Reset permissions on remount if permissions are options\n\nThere\u0027s an inconsistency with the way permissions are handled in tracefs.\nBecause the permissions are generated when accessed, they default to the\nroot inode\u0027s permission if they were never set by the user. If the user\nsets the permissions, then a flag is set and the permissions are saved via\nthe inode (for tracefs files) or an internal attribute field (for\neventfs).\n\nBut if a remount happens that specify the permissions, all the files that\nwere not changed by the user gets updated, but the ones that were are not.\nIf the user were to remount the file system with a given permission, then\nall files and directories within that file system should be updated.\n\nThis can cause security issues if a file\u0027s permission was updated but the\nadmin forgot about it. They could incorrectly think that remounting with\npermissions set would update all files, but miss some.\n\nFor example:\n\n # cd /sys/kernel/tracing\n # chgrp 1002 current_tracer\n # ls -l\n[..]\n -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb\n -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb\n -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb\n -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer\n -rw-r-----  1 root root 0 May  1 21:25 dynamic_events\n -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info\n -r--r-----  1 root root 0 May  1 21:25 enabled_functions\n\nWhere current_tracer now has group \"lkp\".\n\n # mount -o remount,gid=1001 .\n # ls -l\n -rw-r-----  1 root tracing 0 May  1 21:25 buffer_size_kb\n -rw-r-----  1 root tracing 0 May  1 21:25 buffer_subbuf_size_kb\n -r--r-----  1 root tracing 0 May  1 21:25 buffer_total_size_kb\n -rw-r-----  1 root lkp     0 May  1 21:25 current_tracer\n -rw-r-----  1 root tracing 0 May  1 21:25 dynamic_events\n -r--r-----  1 root tracing 0 May  1 21:25 dyn_ftrace_total_info\n -r--r-----  1 root tracing 0 May  1 21:25 enabled_functions\n\nEverything changed but the \"current_tracer\".\n\nAdd a new link list that keeps track of all the tracefs_inodes which has\nthe permission flags that tell if the file/dir should use the root inode\u0027s\npermission or not. Then on remount, clear all the flags so that the\ndefault behavior of using the root inode\u0027s permission is done for all\nfiles and directories.",
  "id": "GHSA-2r24-5j8r-cf83",
  "modified": "2024-06-03T09:30:48Z",
  "published": "2024-06-03T09:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36963"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/414fb08628143203d29ccd0264b5a83fb9523c03"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5f91fc82794d4a6e41cdcd02d00baa377d94ca78"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/baa23a8d4360d981a49913841a726edede5cdd54"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading...

Loading...

Loading...

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.