fkie_cve-2022-49763
Vulnerability from fkie_nvd
Published
2025-05-01 15:15
Modified
2025-05-02 13:53
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: ntfs: fix use-after-free in ntfs_attr_find() Patch series "ntfs: fix bugs about Attribute", v2. This patchset fixes three bugs relative to Attribute in record: Patch 1 adds a sanity check to ensure that, attrs_offset field in first mft record loading from disk is within bounds. Patch 2 moves the ATTR_RECORD's bounds checking earlier, to avoid dereferencing ATTR_RECORD before checking this ATTR_RECORD is within bounds. Patch 3 adds an overflow checking to avoid possible forever loop in ntfs_attr_find(). Without patch 1 and patch 2, the kernel triggersa KASAN use-after-free detection as reported by Syzkaller. Although one of patch 1 or patch 2 can fix this, we still need both of them. Because patch 1 fixes the root cause, and patch 2 not only fixes the direct cause, but also fixes the potential out-of-bounds bug. This patch (of 3): Syzkaller reported use-after-free read as follows: ================================================================== BUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 Read of size 2 at addr ffff88807e352009 by task syz-executor153/3607 [...] Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193 ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845 ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854 mount_bdev+0x34d/0x410 fs/super.c:1400 legacy_get_tree+0x105/0x220 fs/fs_context.c:610 vfs_get_tree+0x89/0x2f0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x1326/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] </TASK> The buggy address belongs to the physical page: page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350 head:ffffea0001f8d400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 0000000000000000 dead000000000122 ffff888011842140 raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Kernel will loads $MFT/$DATA's first mft record in ntfs_read_inode_mount(). Yet the problem is that after loading, kernel doesn't check whether attrs_offset field is a valid value. To be more specific, if attrs_offset field is larger than bytes_allocated field, then it may trigger the out-of-bounds read bug(reported as use-after-free bug) in ntfs_attr_find(), when kernel tries to access the corresponding mft record's attribute. This patch solves it by adding the sanity check between attrs_offset field and bytes_allocated field, after loading the first mft record.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/266bd5306286316758e6246ea0345133427b0f62
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/4863f815463034f588a035cfd99cdca97a4f1069
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5330c423b86263ac7883fef0260b9e2229cb531e
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/79f3ac7dcd12c05b7539239a4c6fa229a50d786c
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b825bfbbaafbe8da2037e3a778ad660c59f9e054
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d0006d739738a658a9c29b438444259d9f71dfa0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d85a1bec8e8d552ab13163ca1874dcd82f3d1550
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/fb2004bafd1932e08d21ca604ee5844f2b7f212d
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: fix use-after-free in ntfs_attr_find()\n\nPatch series \"ntfs: fix bugs about Attribute\", v2.\n\nThis patchset fixes three bugs relative to Attribute in record:\n\nPatch 1 adds a sanity check to ensure that, attrs_offset field in first\nmft record loading from disk is within bounds.\n\nPatch 2 moves the ATTR_RECORD\u0027s bounds checking earlier, to avoid\ndereferencing ATTR_RECORD before checking this ATTR_RECORD is within\nbounds.\n\nPatch 3 adds an overflow checking to avoid possible forever loop in\nntfs_attr_find().\n\nWithout patch 1 and patch 2, the kernel triggersa KASAN use-after-free\ndetection as reported by Syzkaller.\n\nAlthough one of patch 1 or patch 2 can fix this, we still need both of\nthem.  Because patch 1 fixes the root cause, and patch 2 not only fixes\nthe direct cause, but also fixes the potential out-of-bounds bug.\n\n\nThis patch (of 3):\n\nSyzkaller reported use-after-free read as follows:\n==================================================================\nBUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597\nRead of size 2 at addr ffff88807e352009 by task syz-executor153/3607\n\n[...]\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:317 [inline]\n print_report.cold+0x2ba/0x719 mm/kasan/report.c:433\n kasan_report+0xb1/0x1e0 mm/kasan/report.c:495\n ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597\n ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193\n ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845\n ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854\n mount_bdev+0x34d/0x410 fs/super.c:1400\n legacy_get_tree+0x105/0x220 fs/fs_context.c:610\n vfs_get_tree+0x89/0x2f0 fs/super.c:1530\n do_new_mount fs/namespace.c:3040 [inline]\n path_mount+0x1326/0x1e20 fs/namespace.c:3370\n do_mount fs/namespace.c:3383 [inline]\n __do_sys_mount fs/namespace.c:3591 [inline]\n __se_sys_mount fs/namespace.c:3568 [inline]\n __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n [...]\n \u003c/TASK\u003e\n\nThe buggy address belongs to the physical page:\npage:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350\nhead:ffffea0001f8d400 order:3 compound_mapcount:0 compound_pincount:0\nflags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)\nraw: 00fff00000010200 0000000000000000 dead000000000122 ffff888011842140\nraw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\nMemory state around the buggy address:\n ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n\u003effff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                      ^\n ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n==================================================================\n\nKernel will loads $MFT/$DATA\u0027s first mft record in\nntfs_read_inode_mount().\n\nYet the problem is that after loading, kernel doesn\u0027t check whether\nattrs_offset field is a valid value.\n\nTo be more specific, if attrs_offset field is larger than bytes_allocated\nfield, then it may trigger the out-of-bounds read bug(reported as\nuse-after-free bug) in ntfs_attr_find(), when kernel tries to access the\ncorresponding mft record\u0027s attribute.\n\nThis patch solves it by adding the sanity check between attrs_offset field\nand bytes_allocated field, after loading the first mft record."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntfs: correcci\u00f3n del use-after-free en ntfs_attr_find(). Serie de parches \"ntfs: correcci\u00f3n de errores sobre el atributo\", v2. Este conjunto de parches corrige tres errores relacionados con el atributo en el registro: el parche 1 a\u00f1ade una comprobaci\u00f3n de seguridad para garantizar que el campo attrs_offset en la primera carga de registro MFT desde el disco est\u00e9 dentro de los l\u00edmites. El parche 2 adelanta la comprobaci\u00f3n de los l\u00edmites de ATTR_RECORD para evitar desreferenciarlo antes de comprobar que est\u00e9 dentro de los l\u00edmites. El parche 3 a\u00f1ade una comprobaci\u00f3n de desbordamiento para evitar un posible bucle infinito en ntfs_attr_find(). Sin los parches 1 y 2, el kernel activa la detecci\u00f3n de use-after-free de KASAN, seg\u00fan lo informado por Syzkaller. Aunque uno de los parches 1 o 2 puede solucionar esto, a\u00fan necesitamos ambos. Porque el parche 1 corrige la causa ra\u00edz, y el parche 2 no solo corrige la causa directa, sino que tambi\u00e9n corrige el posible error fuera de los l\u00edmites. Este parche (de 3): Syzkaller inform\u00f3 una lectura de use-after-free de la siguiente manera: ====================================================================== ERROR: KASAN: use-after-free en ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 Lectura de tama\u00f1o 2 en la direcci\u00f3n ffff88807e352009 por la tarea syz-executor153/3607 [...] Rastreo de llamadas:  __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193 ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845 ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854 mount_bdev+0x34d/0x410 fs/super.c:1400 legacy_get_tree+0x105/0x220 fs/fs_context.c:610 vfs_get_tree+0x89/0x2f0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x1326/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...]  La direcci\u00f3n con errores pertenece a la p\u00e1gina f\u00edsica: page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350 head:ffffea0001f8d400 order:3 Compound_mapcount:0 Compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 0000000000000000 muerto000000000122 ffff888011842140 raw: 00000000000000000 0000000000040004 00000001ffffffff 0000000000000000 p\u00e1gina volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la direcci\u00f3n con errores: ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc \u0026gt;ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ====================================================================== El n\u00facleo cargar\u00e1 el primer registro mft de $MFT/$DATA en ntfs_read_inode_mount(). Sin embargo, el problema radica en que, tras la carga, el kernel no comprueba si el campo attrs_offset es un valor v\u00e1lido. M\u00e1s espec\u00edficamente, si el campo attrs_offset es mayor que el campo bytes_allocated, podr\u00eda activarse el error de lectura fuera de los l\u00edmites (reportado como error de use-after-free) en ntfs_attr_find() cuando el kernel intenta acceder al atributo del registro MFT correspondiente. Este parche lo soluciona a\u00f1adiendo la comprobaci\u00f3n de validez entre los campos attrs_offset y bytes_allocated tras cargar el primer registro MFT."
    }
  ],
  "id": "CVE-2022-49763",
  "lastModified": "2025-05-02T13:53:20.943",
  "metrics": {},
  "published": "2025-05-01T15:15:59.047",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/266bd5306286316758e6246ea0345133427b0f62"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/4863f815463034f588a035cfd99cdca97a4f1069"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5330c423b86263ac7883fef0260b9e2229cb531e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/79f3ac7dcd12c05b7539239a4c6fa229a50d786c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b825bfbbaafbe8da2037e3a778ad660c59f9e054"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d0006d739738a658a9c29b438444259d9f71dfa0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d85a1bec8e8d552ab13163ca1874dcd82f3d1550"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/fb2004bafd1932e08d21ca604ee5844f2b7f212d"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


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.