{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2023-53531",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2023-53531"
  ],
  "published": "2025-10-01T11:50:00Z",
  "summary": "null_blk: fix poll request timeout handling",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnull_blk: fix poll request timeout handling\n\nWhen doing io_uring benchmark on /dev/nullb0, it's easy to crash the\nkernel if poll requests timeout triggered, as reported by David. [1]\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nWorkqueue: kblockd blk_mq_timeout_work\nRIP: 0010:null_timeout_rq+0x4e/0x91\nCall Trace:\n ? null_timeout_rq+0x4e/0x91\n blk_mq_handle_expired+0x31/0x4b\n bt_iter+0x68/0x84\n ? bt_tags_iter+0x81/0x81\n __sbitmap_for_each_set.constprop.0+0xb0/0xf2\n ? __blk_mq_complete_request_remote+0xf/0xf\n bt_for_each+0x46/0x64\n ? __blk_mq_complete_request_remote+0xf/0xf\n ? percpu_ref_get_many+0xc/0x2a\n blk_mq_queue_tag_busy_iter+0x14d/0x18e\n blk_mq_timeout_work+0x95/0x127\n process_one_work+0x185/0x263\n worker_thread+0x1b5/0x227\n\nThis is indeed a race problem between null_timeout_rq() and null_poll().\n\nnull_poll()\t\t\t\tnull_timeout_rq()\n  spin_lock(&nq->poll_lock)\n  list_splice_init(&nq->poll_list, &list)\n  spin_unlock(&nq->poll_lock)\n\n  while (!list_empty(&list))\n    req = list_first_entry()\n    list_del_init()\n    ...\n    blk_mq_add_to_batch()\n    // req->rq_next = NULL\n\t\t\t\t\tspin_lock(&nq->poll_lock)\n\n\t\t\t\t\t// rq->queuelist->next == NULL\n\t\t\t\t\tlist_del_init(&rq->queuelist)\n\n\t\t\t\t\tspin_unlock(&nq->poll_lock)\n\nFix these problems by setting requests state to MQ_RQ_COMPLETE under\nnq->poll_lock protection, in which null_timeout_rq() can safely detect\nthis race and early return.\n\nNote this patch just fix the kernel panic when request timeout happen.\n\n[1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.54",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-53531"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/a0b4a0666beacfe8add9c71d8922475541dbae73"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/a7cb2e709f2927cc3c76781df3e45de2381b3b9d"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/5a26e45edb4690d58406178b5a9ea4c6dcf2c105"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:24:39Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - Exploitation requires opening the local block device /dev/nullb0 and issuing polled direct I/O (io_uring IOPOLL or preadv2 RWF_HIPRI); there is no remote or adjacent-network path into null_blk.\nAC:L - The attacker controls both sides of the race \u2014 it submits the polled requests, controls when it calls into null_poll(), and the 5-second timeout is fixed unconditionally by null_add_dev() (tag_set->timeout = 5 * HZ), so the collision with blk_mq_timeout_work can be arranged deterministically and retried; the fix author notes it is \"easy to crash the kernel.\"\nPR:L - The vulnerable path contains no capability or namespace check \u2014 any local user able to open the null_blk device node (group disk, benchmarking/CI accounts, or a container handed the device) can reach null_queue_rq/null_poll with ordinary O_DIRECT reads.\nUI:N - The attacker performs the submissions and polling itself; no victim action is required to trigger the race.\nS:U - The corruption is confined to kernel block-layer structures within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - Beyond the NULL case, list_del_init() writes &rq->queuelist into the io_comp_batch chain, so blk_mq_end_request_batch() dereferences a bogus struct request and bio pointers, and the double blk_mq_complete_request() frees the tag twice yielding request reuse \u2014 a UAF-class read primitive over kernel heap contents.\nI:H - The race produces doubly-linked-list corruption plus double request completion (tag double-free and reallocation to a concurrent I/O), giving attacker-influenced kernel heap writes exploitable for control-flow hijacking.\nA:H - The documented result is a kernel NULL pointer dereference oops at address 0x8 inside blk_mq_timeout_work on the kblockd workqueue, killing the worker and panicking or wedging the block layer."
    }
  }
}