ghsa-8wh8-cr52-wj57
Vulnerability from github
Published
2024-05-17 15:31
Modified
2025-02-03 18:30
Details

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

btrfs: fix information leak in btrfs_ioctl_logical_to_ino()

Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino():

BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000

This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory.

Fix this by using kvzalloc() which zeroes out the memory on allocation.

Show details on source website


{
   affected: [],
   aliases: [
      "CVE-2024-35849",
   ],
   database_specific: {
      cwe_ids: [
         "CWE-908",
      ],
      github_reviewed: false,
      github_reviewed_at: null,
      nvd_published_at: "2024-05-17T15:15:21Z",
      severity: "HIGH",
   },
   details: "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix information leak in btrfs_ioctl_logical_to_ino()\n\nSyzbot reported the following information leak for in\nbtrfs_ioctl_logical_to_ino():\n\n  BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n  BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n   instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n   _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n   copy_to_user include/linux/uaccess.h:191 [inline]\n   btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499\n   btrfs_ioctl+0x714/0x1260\n   vfs_ioctl fs/ioctl.c:51 [inline]\n   __do_sys_ioctl fs/ioctl.c:904 [inline]\n   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\n   do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n   do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n  Uninit was created at:\n   __kmalloc_large_node+0x231/0x370 mm/slub.c:3921\n   __do_kmalloc_node mm/slub.c:3954 [inline]\n   __kmalloc_node+0xb07/0x1060 mm/slub.c:3973\n   kmalloc_node include/linux/slab.h:648 [inline]\n   kvmalloc_node+0xc0/0x2d0 mm/util.c:634\n   kvmalloc include/linux/slab.h:766 [inline]\n   init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779\n   btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480\n   btrfs_ioctl+0x714/0x1260\n   vfs_ioctl fs/ioctl.c:51 [inline]\n   __do_sys_ioctl fs/ioctl.c:904 [inline]\n   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\n   do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n   do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n  Bytes 40-65535 of 65536 are uninitialized\n  Memory access of size 65536 starts at ffff888045a40000\n\nThis happens, because we're copying a 'struct btrfs_data_container' back\nto user-space. This btrfs_data_container is allocated in\n'init_data_container()' via kvmalloc(), which does not zero-fill the\nmemory.\n\nFix this by using kvzalloc() which zeroes out the memory on allocation.",
   id: "GHSA-8wh8-cr52-wj57",
   modified: "2025-02-03T18:30:36Z",
   published: "2024-05-17T15:31:12Z",
   references: [
      {
         type: "ADVISORY",
         url: "https://nvd.nist.gov/vuln/detail/CVE-2024-35849",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54",
      },
      {
         type: "WEB",
         url: "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html",
      },
      {
         type: "WEB",
         url: "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html",
      },
   ],
   schema_version: "1.4.0",
   severity: [
      {
         score: "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
         type: "CVSS_V3",
      },
   ],
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



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.