ghsa-97gj-q9fx-vc88
Vulnerability from github
Published
2024-03-04 18:30
Modified
2024-10-31 15:30
Severity ?
3.3 (Low) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Details

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

kfence: fix memory leak when cat kfence objects

Hulk robot reported a kmemleak problem:

unreferenced object 0xffff93d1d8cc02e8 (size 248):
  comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s)
  hex dump (first 32 bytes):
    00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00  .@..............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
     seq_open+0x2a/0x80
     full_proxy_open+0x167/0x1e0
     do_dentry_open+0x1e1/0x3a0
     path_openat+0x961/0xa20
     do_filp_open+0xae/0x120
     do_sys_openat2+0x216/0x2f0
     do_sys_open+0x57/0x80
     do_syscall_64+0x33/0x40
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
unreferenced object 0xffff93d419854000 (size 4096):
  comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s)
  hex dump (first 32 bytes):
    6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30  kfence-#250: 0x0
    30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d  0000000754bda12-
  backtrace:
     seq_read_iter+0x313/0x440
     seq_read+0x14b/0x1a0
     full_proxy_read+0x56/0x80
     vfs_read+0xa5/0x1b0
     ksys_read+0xa0/0xf0
     do_syscall_64+0x33/0x40
     entry_SYSCALL_64_after_hwframe+0x44/0xa9

I find that we can easily reproduce this problem with the following commands:

cat /sys/kernel/debug/kfence/objects
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

The leaked memory is allocated in the stack below:

do_syscall_64
  do_sys_open
    do_dentry_open
      full_proxy_open
        seq_open            ---> alloc seq_file
  vfs_read
    full_proxy_read
      seq_read
        seq_read_iter
          traverse          ---> alloc seq_buf

And it should have been released in the following process:

do_syscall_64
  syscall_exit_to_user_mode
    exit_to_user_mode_prepare
      task_work_run
        ____fput
          __fput
            full_proxy_release  ---> free here

However, the release function corresponding to file_operations is not implemented in kfence. As a result, a memory leak occurs. Therefore, the solution to this problem is to implement the corresponding release function.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-47089"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-04T18:15:07Z",
    "severity": "LOW"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nkfence: fix memory leak when cat kfence objects\n\nHulk robot reported a kmemleak problem:\n\n    unreferenced object 0xffff93d1d8cc02e8 (size 248):\n      comm \"cat\", pid 23327, jiffies 4624670141 (age 495992.217s)\n      hex dump (first 32 bytes):\n        00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00  .@..............\n        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n      backtrace:\n         seq_open+0x2a/0x80\n         full_proxy_open+0x167/0x1e0\n         do_dentry_open+0x1e1/0x3a0\n         path_openat+0x961/0xa20\n         do_filp_open+0xae/0x120\n         do_sys_openat2+0x216/0x2f0\n         do_sys_open+0x57/0x80\n         do_syscall_64+0x33/0x40\n         entry_SYSCALL_64_after_hwframe+0x44/0xa9\n    unreferenced object 0xffff93d419854000 (size 4096):\n      comm \"cat\", pid 23327, jiffies 4624670141 (age 495992.217s)\n      hex dump (first 32 bytes):\n        6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30  kfence-#250: 0x0\n        30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d  0000000754bda12-\n      backtrace:\n         seq_read_iter+0x313/0x440\n         seq_read+0x14b/0x1a0\n         full_proxy_read+0x56/0x80\n         vfs_read+0xa5/0x1b0\n         ksys_read+0xa0/0xf0\n         do_syscall_64+0x33/0x40\n         entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nI find that we can easily reproduce this problem with the following\ncommands:\n\n\tcat /sys/kernel/debug/kfence/objects\n\techo scan \u003e /sys/kernel/debug/kmemleak\n\tcat /sys/kernel/debug/kmemleak\n\nThe leaked memory is allocated in the stack below:\n\n    do_syscall_64\n      do_sys_open\n        do_dentry_open\n          full_proxy_open\n            seq_open            ---\u003e alloc seq_file\n      vfs_read\n        full_proxy_read\n          seq_read\n            seq_read_iter\n              traverse          ---\u003e alloc seq_buf\n\nAnd it should have been released in the following process:\n\n    do_syscall_64\n      syscall_exit_to_user_mode\n        exit_to_user_mode_prepare\n          task_work_run\n            ____fput\n              __fput\n                full_proxy_release  ---\u003e free here\n\nHowever, the release function corresponding to file_operations is not\nimplemented in kfence.  As a result, a memory leak occurs.  Therefore,\nthe solution to this problem is to implement the corresponding release\nfunction.",
  "id": "GHSA-97gj-q9fx-vc88",
  "modified": "2024-10-31T15:30:57Z",
  "published": "2024-03-04T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47089"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0129ab1f268b6cf88825eae819b9b84aa0a85634"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2f06c8293d27f6337f907042c602c9c953988c48"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.