ghsa-2482-hx3h-75g4
Vulnerability from github
Published
2024-10-21 21:30
Modified
2024-10-25 18:30
Severity ?
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Details

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

io_uring: Fix a null-ptr-deref in io_tctx_exit_cb()

Syzkaller reports a NULL deref bug as follows:

BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3 Read of size 4 at addr 0000000000000138 by task file1/1955

CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Call Trace: dump_stack_lvl+0xcd/0x134 ? io_tctx_exit_cb+0x53/0xd3 kasan_report+0xbb/0x1f0 ? io_tctx_exit_cb+0x53/0xd3 kasan_check_range+0x140/0x190 io_tctx_exit_cb+0x53/0xd3 task_work_run+0x164/0x250 ? task_work_cancel+0x30/0x30 get_signal+0x1c3/0x2440 ? lock_downgrade+0x6e0/0x6e0 ? lock_downgrade+0x6e0/0x6e0 ? exit_signals+0x8b0/0x8b0 ? do_raw_read_unlock+0x3b/0x70 ? do_raw_spin_unlock+0x50/0x230 arch_do_signal_or_restart+0x82/0x2470 ? kmem_cache_free+0x260/0x4b0 ? putname+0xfe/0x140 ? get_sigframe_size+0x10/0x10 ? do_execveat_common.isra.0+0x226/0x710 ? lockdep_hardirqs_on+0x79/0x100 ? putname+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Kernel panic - not syncing: panic_on_warn set ...

This happens because the adding of task_work from io_ring_exit_work() isn't synchronized with canceling all work items from eg exec. The execution of the two are ordered in that they are both run by the task itself, but if io_tctx_exit_cb() is queued while we're canceling all work items off exec AND gets executed when the task exits to userspace rather than in the main loop in io_uring_cancel_generic(), then we can find current->io_uring == NULL and hit the above crash.

It's safe to add this NULL check here, because the execution of the two paths are done by the task itself.

[axboe: add code comment and also put an explanation in the commit msg]

Show details on source website

To clipboard 

{
   affected: [],
   aliases: [
      "CVE-2022-48983",
   ],
   database_specific: {
      cwe_ids: [
         "CWE-476",
      ],
      github_reviewed: false,
      github_reviewed_at: null,
      nvd_published_at: "2024-10-21T20:15:10Z",
      severity: "MODERATE",
   },
   details: "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: Fix a null-ptr-deref in io_tctx_exit_cb()\n\nSyzkaller reports a NULL deref bug as follows:\n\n BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3\n Read of size 4 at addr 0000000000000138 by task file1/1955\n\n CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0xcd/0x134\n  ? io_tctx_exit_cb+0x53/0xd3\n  kasan_report+0xbb/0x1f0\n  ? io_tctx_exit_cb+0x53/0xd3\n  kasan_check_range+0x140/0x190\n  io_tctx_exit_cb+0x53/0xd3\n  task_work_run+0x164/0x250\n  ? task_work_cancel+0x30/0x30\n  get_signal+0x1c3/0x2440\n  ? lock_downgrade+0x6e0/0x6e0\n  ? lock_downgrade+0x6e0/0x6e0\n  ? exit_signals+0x8b0/0x8b0\n  ? do_raw_read_unlock+0x3b/0x70\n  ? do_raw_spin_unlock+0x50/0x230\n  arch_do_signal_or_restart+0x82/0x2470\n  ? kmem_cache_free+0x260/0x4b0\n  ? putname+0xfe/0x140\n  ? get_sigframe_size+0x10/0x10\n  ? do_execveat_common.isra.0+0x226/0x710\n  ? lockdep_hardirqs_on+0x79/0x100\n  ? putname+0xfe/0x140\n  ? do_execveat_common.isra.0+0x238/0x710\n  exit_to_user_mode_prepare+0x15f/0x250\n  syscall_exit_to_user_mode+0x19/0x50\n  do_syscall_64+0x42/0xb0\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0023:0x0\n Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\n R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n  </TASK>\n Kernel panic - not syncing: panic_on_warn set ...\n\nThis happens because the adding of task_work from io_ring_exit_work()\nisn't synchronized with canceling all work items from eg exec. The\nexecution of the two are ordered in that they are both run by the task\nitself, but if io_tctx_exit_cb() is queued while we're canceling all\nwork items off exec AND gets executed when the task exits to userspace\nrather than in the main loop in io_uring_cancel_generic(), then we can\nfind current->io_uring == NULL and hit the above crash.\n\nIt's safe to add this NULL check here, because the execution of the two\npaths are done by the task itself.\n\n[axboe: add code comment and also put an explanation in the commit msg]",
   id: "GHSA-2482-hx3h-75g4",
   modified: "2024-10-25T18:30:47Z",
   published: "2024-10-21T21:30:51Z",
   references: [
      {
         type: "ADVISORY",
         url: "https://nvd.nist.gov/vuln/detail/CVE-2022-48983",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/998b30c3948e4d0b1097e639918c5cff332acac5",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/d91edca1943453aaaba4f380f6f364346222e5cf",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/f895511de9d27fff71dad2c234ad53b4afd2b06c",
      },
   ],
   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: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.




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.