« Volver al listado

CVE-2023-53836

Estado: AplazadaAlta (7.8)—

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

bpf, sockmap: Fix skb refcnt race after locking changes

There is a race where skb's from the sk_psock_backlog can be referenced after userspace side has already skb_consumed() the sk_buff and its refcnt dropped to zer0 causing use after free.

The flow is the following:

The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is what the application reads when recvmsg() is called. An application can read this anytime after the msg is placed on the queue. The recvmsg hook will also read msg->skb and then after user space reads the msg will call consume_skb(skb) on it effectively free'ing it.

Leer descripción completaMostrar menos

But, the race is in above where backlog queue still has a reference to the skb and calls skb_dequeue(). If the skb_dequeue happens after the user reads and free's the skb we have a use after free.

The !ingress case does not suffer from this problem because it uses sendmsg_*(sk, msg) which does not pass the sk_buff further down the stack.

The following splat was observed with 'test_progs -t sockmap_listen':

To fix we add an skb_get() before passing the skb to be enqueued in the engress queue. This bumps the skb->users refcnt so that consume_skb() and kfree_skb will not immediately free the sk_buff. With this we can be sure the skb is still around when we do the dequeue. Then we just need to decrement the refcnt or free the skb in the backlog case which we do by calling kfree_skb() on the ingress case as well as the sendmsg case.

Before locking change from fixes tag we had the sock locked so we couldn't race with user and there was no issue here.

Detalles técnicos trazas, registros y código del informe original
  while ((skb = skb_peek(&psock->ingress_skb))
    sk_psock_handle_Skb(psock, skb, ..., ingress)
    if (!ingress) ...
    sk_psock_skb_ingress
       sk_psock_skb_ingress_enqueue(skb)
          msg->skb = skb
          sk_psock_queue_msg(psock, msg)
    skb_dequeue(&psock->ingress_skb)

  [ 1022.710250][ T2556] general protection fault, ...
  [...]
  [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog
  [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80
  [ 1022.713653][ T2556] Code: ...
  [...]
  [ 1022.720699][ T2556] Call Trace:
  [ 1022.720984][ T2556]  <TASK>
  [ 1022.721254][ T2556]  ? die_addr+0x32/0x80^M
  [ 1022.721589][ T2556]  ? exc_general_protection+0x25a/0x4b0
  [ 1022.722026][ T2556]  ? asm_exc_general_protection+0x22/0x30
  [ 1022.722489][ T2556]  ? skb_dequeue+0x4c/0x80
  [ 1022.722854][ T2556]  sk_psock_backlog+0x27a/0x300
  [ 1022.723243][ T2556]  process_one_work+0x2a7/0x5b0
  [ 1022.723633][ T2556]  worker_thread+0x4f/0x3a0
  [ 1022.723998][ T2556]  ? __pfx_worker_thread+0x10/0x10
  [ 1022.724386][ T2556]  kthread+0xfd/0x130
  [ 1022.724709][ T2556]  ? __pfx_kthread+0x10/0x10
  [ 1022.725066][ T2556]  ret_from_fork+0x2d/0x50
  [ 1022.725409][ T2556]  ? __pfx_kthread+0x10/0x10
  [ 1022.725799][ T2556]  ret_from_fork_asm+0x1b/0x30
  [ 1022.726201][ T2556]  </TASK>

CVSS

Probabilidad de explotación (EPSS)

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

🎯 Técnicas ATT&CK

Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.

AV:L/PR:L/UI:N sin privilegios elevados indica escalada local. Race condition en refcuenta causa DoS (crash de kernel) e integridad de datos (use-after-free).

Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.

🛡️ Mitigaciones ATT&CK que cubren estas técnicas

Threat Intelligence ProgramRestrict File and Directory PermissionsRemote Data StorageFilter Network TrafficExecution PreventionEncrypt Sensitive Information

Tecnologías afectadas (1)

⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.

Linux — Linux KernelAI

Referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2023-53836",
  "cveTags": [],
  "metrics": {
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 7.8,
          "attackVector": "LOCAL",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.9,
        "exploitabilityScore": 1.8
      }
    ]
  },
  "affected": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "affectedData": [
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3",
              "lessThan": "65ad600b9bde68d2d28709943ab00b51ca8f0a1d",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3",
              "lessThan": "923877254f002ae87d441382bb1096d9e773d56d",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3",
              "lessThan": "e6b5e47adb9166e732cdf7e6e034946e3f89f36d",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "799aa7f98d53e0f541fa6b4dc9aa47b4ff2178e3",
              "lessThan": "a454d84ee20baf7bd7be90721b9821f73c7d23d9",
              "versionType": "git"
            }
          ],
          "programFiles": [
            "net/core/skmsg.c"
          ],
          "defaultStatus": "unaffected"
        },
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.13"
            },
            {
              "status": "unaffected",
              "version": "0",
              "lessThan": "5.13",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "5.15.189",
              "versionType": "semver",
              "lessThanOrEqual": "5.15.*"
            },
            {
              "status": "unaffected",
              "version": "6.1.54",
              "versionType": "semver",
              "lessThanOrEqual": "6.1.*"
            },
            {
              "status": "unaffected",
              "version": "6.5.4",
              "versionType": "semver",
              "lessThanOrEqual": "6.5.*"
            },
            {
              "status": "unaffected",
              "version": "6.6",
              "versionType": "original_commit_for_fix",
              "lessThanOrEqual": "*"
            }
          ],
          "programFiles": [
            "net/core/skmsg.c"
          ],
          "defaultStatus": "affected"
        }
      ]
    }
  ],
  "published": "2025-12-09T16:17:22.887",
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/65ad600b9bde68d2d28709943ab00b51ca8f0a1d",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/923877254f002ae87d441382bb1096d9e773d56d",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/a454d84ee20baf7bd7be90721b9821f73c7d23d9",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/e6b5e47adb9166e732cdf7e6e034946e3f89f36d",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "vulnStatus": "Deferred",
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix skb refcnt race after locking changes\n\nThere is a race where skb's from the sk_psock_backlog can be referenced\nafter userspace side has already skb_consumed() the sk_buff and its refcnt\ndropped to zer0 causing use after free.\n\nThe flow is the following:\n\n  while ((skb = skb_peek(&psock->ingress_skb))\n    sk_psock_handle_Skb(psock, skb, ..., ingress)\n    if (!ingress) ...\n    sk_psock_skb_ingress\n       sk_psock_skb_ingress_enqueue(skb)\n          msg->skb = skb\n          sk_psock_queue_msg(psock, msg)\n    skb_dequeue(&psock->ingress_skb)\n\nThe sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is\nwhat the application reads when recvmsg() is called. An application can\nread this anytime after the msg is placed on the queue. The recvmsg hook\nwill also read msg->skb and then after user space reads the msg will call\nconsume_skb(skb) on it effectively free'ing it.\n\nBut, the race is in above where backlog queue still has a reference to\nthe skb and calls skb_dequeue(). If the skb_dequeue happens after the\nuser reads and free's the skb we have a use after free.\n\nThe !ingress case does not suffer from this problem because it uses\nsendmsg_*(sk, msg) which does not pass the sk_buff further down the\nstack.\n\nThe following splat was observed with 'test_progs -t sockmap_listen':\n\n  [ 1022.710250][ T2556] general protection fault, ...\n  [...]\n  [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog\n  [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80\n  [ 1022.713653][ T2556] Code: ...\n  [...]\n  [ 1022.720699][ T2556] Call Trace:\n  [ 1022.720984][ T2556]  <TASK>\n  [ 1022.721254][ T2556]  ? die_addr+0x32/0x80^M\n  [ 1022.721589][ T2556]  ? exc_general_protection+0x25a/0x4b0\n  [ 1022.722026][ T2556]  ? asm_exc_general_protection+0x22/0x30\n  [ 1022.722489][ T2556]  ? skb_dequeue+0x4c/0x80\n  [ 1022.722854][ T2556]  sk_psock_backlog+0x27a/0x300\n  [ 1022.723243][ T2556]  process_one_work+0x2a7/0x5b0\n  [ 1022.723633][ T2556]  worker_thread+0x4f/0x3a0\n  [ 1022.723998][ T2556]  ? __pfx_worker_thread+0x10/0x10\n  [ 1022.724386][ T2556]  kthread+0xfd/0x130\n  [ 1022.724709][ T2556]  ? __pfx_kthread+0x10/0x10\n  [ 1022.725066][ T2556]  ret_from_fork+0x2d/0x50\n  [ 1022.725409][ T2556]  ? __pfx_kthread+0x10/0x10\n  [ 1022.725799][ T2556]  ret_from_fork_asm+0x1b/0x30\n  [ 1022.726201][ T2556]  </TASK>\n\nTo fix we add an skb_get() before passing the skb to be enqueued in the\nengress queue. This bumps the skb->users refcnt so that consume_skb()\nand kfree_skb will not immediately free the sk_buff. With this we can\nbe sure the skb is still around when we do the dequeue. Then we just\nneed to decrement the refcnt or free the skb in the backlog case which\nwe do by calling kfree_skb() on the ingress case as well as the sendmsg\ncase.\n\nBefore locking change from fixes tag we had the sock locked so we\ncouldn't race with user and there was no issue here."
    }
  ],
  "lastModified": "2026-08-04T10:19:23.570",
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}