{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-53100",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-53100"
  ],
  "published": "2024-11-25T21:21:15Z",
  "summary": "nvme: tcp: avoid race between queue_lock lock and destroy",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: tcp: avoid race between queue_lock lock and destroy\n\nCommit 76d54bf20cdc (\"nvme-tcp: don't access released socket during\nerror recovery\") added a mutex_lock() call for the queue->queue_lock\nin nvme_tcp_get_address(). However, the mutex_lock() races with\nmutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.\n\nDEBUG_LOCKS_WARN_ON(lock->magic != lock)\nWARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220\nModules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs]\nCPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:__mutex_lock+0xcf0/0x1220\nCode: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1\nRSP: 0018:ffff88811305f760 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001\nRBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341\nR10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058\nFS:  00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ? __warn.cold+0x5b/0x1af\n ? __mutex_lock+0xcf0/0x1220\n ? report_bug+0x1ec/0x390\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x13/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? __mutex_lock+0xcf0/0x1220\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx___mutex_lock+0x10/0x10\n ? __lock_acquire+0xd6a/0x59e0\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp]\n nvme_sysfs_show_address+0x81/0xc0 [nvme_core]\n dev_attr_show+0x42/0x80\n ? __asan_memset+0x1f/0x40\n sysfs_kf_seq_show+0x1f0/0x370\n seq_read_iter+0x2cb/0x1130\n ? rw_verify_area+0x3b1/0x590\n ? __mutex_lock+0x433/0x1220\n vfs_read+0x6a6/0xa20\n ? lockdep_hardirqs_on+0x78/0x100\n ? __pfx_vfs_read+0x10/0x10\n ksys_read+0xf7/0x1d0\n ? __pfx_ksys_read+0x10/0x10\n ? __x64_sys_openat+0x105/0x1d0\n do_syscall_64+0x93/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? __pfx_ksys_read+0x10/0x10\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? do_syscall_64+0x9f/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f9713f55cfa\nCode: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4\n---truncated---",
  "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.118",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-53100"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/4f946479b326a3cbb193f2b8368aed9269514c35"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/975cb1d2121511584695d0e47fdb90e6782da007"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/e15cebc1b21856944b387f4abd03b66bd3d4f027"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/782373ba27660ba7d330208cf5509ece6feb4545"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:52:36Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerable function `nvme_tcp_get_address()` is only entered through a local `read()` syscall on the sysfs attribute `/sys/class/nvme/nvmeN/address` (`nvme_sysfs_show_address` \u2192 `ctrl->ops->get_address`), so the attacker must have local access to the host. A remote NVMe/TCP target or on-path attacker can drive the other half of the race (connection drop \u2192 `nvme_tcp_error_recovery_work` \u2192 `nvme_tcp_free_queue()`/`mutex_destroy` \u2192 reconnect `mutex_init`), but the vulnerable code itself is only reachable locally.\nAC:L - The attacker drives both sides of the race: an unlimited loop of `read()` on the world-readable address attribute plus repeated controller reset/reconnect cycles (root-triggered reset, or remotely induced error recovery by flapping the TCP connection), and the commit notes the window is hit by simple repetition of blktests nvme/014. A narrow window that can be retried indefinitely by the attacker is Low complexity.\nPR:L - The `address` attribute is declared `DEVICE_ATTR(address, S_IRUGO, ...)` (mode 0444), so any unprivileged local user can open and read it in a tight loop to enter `nvme_tcp_get_address()` and hit the destroyed/re-initialized `queue->queue_lock`. No capability, namespace, or CAP_SYS_ADMIN check exists on this path.\nUI:N - No victim action is needed \u2014 the attacker's own reads of the sysfs file supply the racing thread, and the teardown side occurs automatically on controller error recovery/reconnect. System daemons (udisksd, udev, nvme-cli) additionally read this attribute unprompted, as shown in the reported trace.\nS:U - The lock-lifetime bug and its consequences (WARN, hung task, released-socket access) are confined to the kernel of the affected host; no VM, IOMMU, or sandbox boundary is crossed. This is a standard same-authority kernel defect.\nC:H - `mutex_destroy()` in `nvme_tcp_free_queue()` and the subsequent `mutex_init()` in `nvme_tcp_alloc_queue()` on the same live memory void the mutual exclusion that commit 76d54bf20cdc added, re-opening access to a released socket: `kernel_getsockname(queue->sock)` can run on a `struct socket` whose file was already `fput()`ed, reading freed memory whose contents are then formatted into the `src_addr=` string returned to the unprivileged reader. That is a use-after-free read with the leaked bytes delivered straight to userspace.\nI:H - The same use-after-free reaches an indirect call through `sock->ops->getname` on freed memory, and `mutex_init()` resetting `owner`, `wait_lock`, and `wait_list` while another task holds or waits on the mutex corrupts the wait list \u2014 both give heap-grooming-based control-flow/write primitives per use-after-free scoring guidance.\nA:H - The reported and reproduced effect is a `DEBUG_LOCKS_WARN_ON(lock->magic != lock)` WARNING in `__mutex_lock()`, which is a panic on the many hardened/cloud kernels running `panic_on_warn`. The broken locking additionally yields NULL-pointer dereference of `queue->sock`, use-after-free oopses, and orphaned mutex waiters that hang indefinitely."
    }
  }
}