CVE-2024-35970 (GCVE-0-2024-35970)

Vulnerability from cvelistv5 – Published: 2024-05-20 09:41 – Updated: 2026-05-11 20:14
VLAI
Title
af_unix: Clear stale u->oob_skb.
Summary
In the Linux kernel, the following vulnerability has been resolved: af_unix: Clear stale u->oob_skb. syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() # done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB, manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI. Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is called twice without MSG_OOB, the OOB data should be lost. >>> from socket import * >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSG_OOB) # This should return an error b'o' In the same situation, TCP actually returns -EINVAL for the last recv(). Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set EPOLLPRI even though the data has passed through by previous recv(). To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing it from recv queue. The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop. When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket. With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue.
Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 314001f0bf927015e459c9d387d62a231fe93af3 , < b4bc99d04c689b5652665394ae8d3e02fb754153 (git)
Affected: 314001f0bf927015e459c9d387d62a231fe93af3 , < 84a352b7eba1142a95441380058985ff19f25ec9 (git)
Affected: 314001f0bf927015e459c9d387d62a231fe93af3 , < 601a89ea24d05089debfa2dc896ea9f5937ac7a6 (git)
Affected: 314001f0bf927015e459c9d387d62a231fe93af3 , < 698a95ade1a00e6494482046902b986dfffd1caf (git)
Affected: 314001f0bf927015e459c9d387d62a231fe93af3 , < b46f4eaa4f0ec38909fb0072eea3aeddb32f954e (git)
Create a notification for this product.
Linux Linux Affected: 5.15
Unaffected: 0 , < 5.15 (semver)
Unaffected: 5.15.156 , ≤ 5.15.* (semver)
Unaffected: 6.1.87 , ≤ 6.1.* (semver)
Unaffected: 6.6.28 , ≤ 6.6.* (semver)
Unaffected: 6.8.7 , ≤ 6.8.* (semver)
Unaffected: 6.9 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "LOW",
              "baseScore": 6.3,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "LOW",
              "integrityImpact": "LOW",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2024-35970",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-05-20T14:23:05.468197Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "description": "CWE-noinfo Not enough information",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-11-01T18:47:14.276Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T03:21:49.053Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/unix/af_unix.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "b4bc99d04c689b5652665394ae8d3e02fb754153",
              "status": "affected",
              "version": "314001f0bf927015e459c9d387d62a231fe93af3",
              "versionType": "git"
            },
            {
              "lessThan": "84a352b7eba1142a95441380058985ff19f25ec9",
              "status": "affected",
              "version": "314001f0bf927015e459c9d387d62a231fe93af3",
              "versionType": "git"
            },
            {
              "lessThan": "601a89ea24d05089debfa2dc896ea9f5937ac7a6",
              "status": "affected",
              "version": "314001f0bf927015e459c9d387d62a231fe93af3",
              "versionType": "git"
            },
            {
              "lessThan": "698a95ade1a00e6494482046902b986dfffd1caf",
              "status": "affected",
              "version": "314001f0bf927015e459c9d387d62a231fe93af3",
              "versionType": "git"
            },
            {
              "lessThan": "b46f4eaa4f0ec38909fb0072eea3aeddb32f954e",
              "status": "affected",
              "version": "314001f0bf927015e459c9d387d62a231fe93af3",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/unix/af_unix.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.15"
            },
            {
              "lessThan": "5.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.156",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.87",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.28",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.9",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.156",
                  "versionStartIncluding": "5.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.87",
                  "versionStartIncluding": "5.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.28",
                  "versionStartIncluding": "5.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.8.7",
                  "versionStartIncluding": "5.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.9",
                  "versionStartIncluding": "5.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Clear stale u-\u003eoob_skb.\n\nsyzkaller started to report deadlock of unix_gc_lock after commit\n4090fa373f0e (\"af_unix: Replace garbage collection algorithm.\"), but\nit just uncovers the bug that has been there since commit 314001f0bf92\n(\"af_unix: Add OOB support\").\n\nThe repro basically does the following.\n\n  from socket import *\n  from array import array\n\n  c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)\n  c1.sendmsg([b\u0027a\u0027], [(SOL_SOCKET, SCM_RIGHTS, array(\"i\", [c2.fileno()]))], MSG_OOB)\n  c2.recv(1)  # blocked as no normal data in recv queue\n\n  c2.close()  # done async and unblock recv()\n  c1.close()  # done async and trigger GC\n\nA socket sends its file descriptor to itself as OOB data and tries to\nreceive normal data, but finally recv() fails due to async close().\n\nThe problem here is wrong handling of OOB skb in manage_oob().  When\nrecvmsg() is called without MSG_OOB, manage_oob() is called to check\nif the peeked skb is OOB skb.  In such a case, manage_oob() pops it\nout of the receive queue but does not clear unix_sock(sk)-\u003eoob_skb.\nThis is wrong in terms of uAPI.\n\nLet\u0027s say we send \"hello\" with MSG_OOB, and \"world\" without MSG_OOB.\nThe \u0027o\u0027 is handled as OOB data.  When recv() is called twice without\nMSG_OOB, the OOB data should be lost.\n\n  \u003e\u003e\u003e from socket import *\n  \u003e\u003e\u003e c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)\n  \u003e\u003e\u003e c1.send(b\u0027hello\u0027, MSG_OOB)  # \u0027o\u0027 is OOB data\n  5\n  \u003e\u003e\u003e c1.send(b\u0027world\u0027)\n  5\n  \u003e\u003e\u003e c2.recv(5)  # OOB data is not received\n  b\u0027hell\u0027\n  \u003e\u003e\u003e c2.recv(5)  # OOB date is skipped\n  b\u0027world\u0027\n  \u003e\u003e\u003e c2.recv(5, MSG_OOB)  # This should return an error\n  b\u0027o\u0027\n\nIn the same situation, TCP actually returns -EINVAL for the last\nrecv().\n\nAlso, if we do not clear unix_sk(sk)-\u003eoob_skb, unix_poll() always set\nEPOLLPRI even though the data has passed through by previous recv().\n\nTo avoid these issues, we must clear unix_sk(sk)-\u003eoob_skb when dequeuing\nit from recv queue.\n\nThe reason why the old GC did not trigger the deadlock is because the\nold GC relied on the receive queue to detect the loop.\n\nWhen it is triggered, the socket with OOB data is marked as GC candidate\nbecause file refcount == inflight count (1).  However, after traversing\nall inflight sockets, the socket still has a positive inflight count (1),\nthus the socket is excluded from candidates.  Then, the old GC lose the\nchance to garbage-collect the socket.\n\nWith the old GC, the repro continues to create true garbage that will\nnever be freed nor detected by kmemleak as it\u0027s linked to the global\ninflight list.  That\u0027s why we couldn\u0027t even notice the issue."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:14:43.690Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153"
        },
        {
          "url": "https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9"
        },
        {
          "url": "https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6"
        },
        {
          "url": "https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf"
        },
        {
          "url": "https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e"
        }
      ],
      "title": "af_unix: Clear stale u-\u003eoob_skb.",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-35970",
    "datePublished": "2024-05-20T09:41:58.524Z",
    "dateReserved": "2024-05-17T13:50:33.141Z",
    "dateUpdated": "2026-05-11T20:14:43.690Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-35970",
      "date": "2026-06-03",
      "epss": "0.00058",
      "percentile": "0.18228"
    },
    "fkie_nvd": {
      "descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\naf_unix: Clear stale u-\u003eoob_skb.\\n\\nsyzkaller started to report deadlock of unix_gc_lock after commit\\n4090fa373f0e (\\\"af_unix: Replace garbage collection algorithm.\\\"), but\\nit just uncovers the bug that has been there since commit 314001f0bf92\\n(\\\"af_unix: Add OOB support\\\").\\n\\nThe repro basically does the following.\\n\\n  from socket import *\\n  from array import array\\n\\n  c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)\\n  c1.sendmsg([b\u0027a\u0027], [(SOL_SOCKET, SCM_RIGHTS, array(\\\"i\\\", [c2.fileno()]))], MSG_OOB)\\n  c2.recv(1)  # blocked as no normal data in recv queue\\n\\n  c2.close()  # done async and unblock recv()\\n  c1.close()  # done async and trigger GC\\n\\nA socket sends its file descriptor to itself as OOB data and tries to\\nreceive normal data, but finally recv() fails due to async close().\\n\\nThe problem here is wrong handling of OOB skb in manage_oob().  When\\nrecvmsg() is called without MSG_OOB, manage_oob() is called to check\\nif the peeked skb is OOB skb.  In such a case, manage_oob() pops it\\nout of the receive queue but does not clear unix_sock(sk)-\u003eoob_skb.\\nThis is wrong in terms of uAPI.\\n\\nLet\u0027s say we send \\\"hello\\\" with MSG_OOB, and \\\"world\\\" without MSG_OOB.\\nThe \u0027o\u0027 is handled as OOB data.  When recv() is called twice without\\nMSG_OOB, the OOB data should be lost.\\n\\n  \u003e\u003e\u003e from socket import *\\n  \u003e\u003e\u003e c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)\\n  \u003e\u003e\u003e c1.send(b\u0027hello\u0027, MSG_OOB)  # \u0027o\u0027 is OOB data\\n  5\\n  \u003e\u003e\u003e c1.send(b\u0027world\u0027)\\n  5\\n  \u003e\u003e\u003e c2.recv(5)  # OOB data is not received\\n  b\u0027hell\u0027\\n  \u003e\u003e\u003e c2.recv(5)  # OOB date is skipped\\n  b\u0027world\u0027\\n  \u003e\u003e\u003e c2.recv(5, MSG_OOB)  # This should return an error\\n  b\u0027o\u0027\\n\\nIn the same situation, TCP actually returns -EINVAL for the last\\nrecv().\\n\\nAlso, if we do not clear unix_sk(sk)-\u003eoob_skb, unix_poll() always set\\nEPOLLPRI even though the data has passed through by previous recv().\\n\\nTo avoid these issues, we must clear unix_sk(sk)-\u003eoob_skb when dequeuing\\nit from recv queue.\\n\\nThe reason why the old GC did not trigger the deadlock is because the\\nold GC relied on the receive queue to detect the loop.\\n\\nWhen it is triggered, the socket with OOB data is marked as GC candidate\\nbecause file refcount == inflight count (1).  However, after traversing\\nall inflight sockets, the socket still has a positive inflight count (1),\\nthus the socket is excluded from candidates.  Then, the old GC lose the\\nchance to garbage-collect the socket.\\n\\nWith the old GC, the repro continues to create true garbage that will\\nnever be freed nor detected by kmemleak as it\u0027s linked to the global\\ninflight list.  That\u0027s why we couldn\u0027t even notice the issue.\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Borrar u-\u0026gt;oob_skb obsoleto. syzkaller comenz\\u00f3 a informar un punto muerto de unix_gc_lock despu\\u00e9s de la confirmaci\\u00f3n 4090fa373f0e (\\\"af_unix: Reemplazar el algoritmo de recolecci\\u00f3n de basura\\\"), pero simplemente descubre el error que ha estado ah\\u00ed desde la confirmaci\\u00f3n 314001f0bf92 (\\\"af_unix: Agregar soporte OOB\\\"). La reproducci\\u00f3n b\\u00e1sicamente hace lo siguiente. desde importaci\\u00f3n de socket * desde matriz de importaci\\u00f3n matriz c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b\u0027a\u0027], [(SOL_SOCKET, SCM_RIGHTS, array(\\\"i\\\", [c2.fileno()])) ], MSG_OOB) c2.recv(1) # bloqueado porque no hay datos normales en la cola de recepci\\u00f3n c2.close() # hecho as\\u00edncrono y desbloquea recv() c1.close() # hecho as\\u00edncrono y activa GC Un socket env\\u00eda su descriptor de archivo a como datos OOB e intenta recibir datos normales, pero finalmente recv() falla debido al cierre as\\u00edncrono(). El problema aqu\\u00ed es el manejo incorrecto de OOB skb en Manage_oob(). Cuando se llama a recvmsg() sin MSG_OOB, se llama a Manage_oob() para verificar si el skb visto es skb OOB. En tal caso, Manage_oob() lo saca de la cola de recepci\\u00f3n pero no borra unix_sock(sk)-\u0026gt;oob_skb. Esto est\\u00e1 mal en t\\u00e9rminos de uAPI. Digamos que enviamos \\\"hola\\\" con MSG_OOB y \\\"mundo\\\" sin MSG_OOB. La \u0027o\u0027 se maneja como datos OOB. Cuando se llama a recv() dos veces sin MSG_OOB, los datos OOB deber\\u00edan perderse. \u0026gt;\u0026gt;\u0026gt; desde importaci\\u00f3n de socket * \u0026gt;\u0026gt;\u0026gt; c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) \u0026gt;\u0026gt;\u0026gt; c1.send(b\u0027hello\u0027, MSG_OOB) # \u0027o\u0027 son datos OOB 5 \u0026gt;\u0026gt;\u0026gt; c1.send (b\u0027world\u0027) 5 \u0026gt;\u0026gt;\u0026gt; c2.recv(5) # Los datos OOB no se reciben b\u0027hell\u0027 \u0026gt;\u0026gt;\u0026gt; c2.recv(5) # La fecha OOB se omite b\u0027world\u0027 \u0026gt;\u0026gt;\u0026gt; c2.recv (5, MSG_OOB) # Esto deber\\u00eda devolver un error b\u0027o\u0027. En la misma situaci\\u00f3n, TCP en realidad devuelve -EINVAL para el \\u00faltimo recv(). Adem\\u00e1s, si no borramos unix_sk(sk)-\u0026gt;oob_skb, unix_poll() siempre establece EPOLLPRI aunque los datos hayan pasado por el recv() anterior. Para evitar estos problemas, debemos borrar unix_sk(sk)-\u0026gt;oob_skb al retirarlo de la cola de recepci\\u00f3n. La raz\\u00f3n por la que el antiguo GC no provoc\\u00f3 el punto muerto es porque el antiguo GC depend\\u00eda de la cola de recepci\\u00f3n para detectar el bucle. Cuando se activa, el socket con datos OOB se marca como candidato de GC porque el recuento de archivos == recuento en vuelo (1). Sin embargo, despu\\u00e9s de atravesar todos los sockets en vuelo, el socket todav\\u00eda tiene un recuento positivo en vuelo (1), por lo que el socket queda excluido de los candidatos. Entonces, el antiguo GC pierde la oportunidad de recolectar basura en el socket. Con el antiguo GC, la reproducci\\u00f3n contin\\u00faa creando verdadera basura que kmemleak nunca liberar\\u00e1 ni detectar\\u00e1, ya que est\\u00e1 vinculada a la lista global a bordo. Por eso ni siquiera pudimos notar el problema.\"}]",
      "id": "CVE-2024-35970",
      "lastModified": "2024-11-21T09:21:19.513",
      "metrics": "{\"cvssMetricV31\": [{\"source\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"type\": \"Secondary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L\", \"baseScore\": 6.3, \"baseSeverity\": \"MEDIUM\", \"attackVector\": \"NETWORK\", \"attackComplexity\": \"LOW\", \"privilegesRequired\": \"LOW\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"LOW\", \"integrityImpact\": \"LOW\", \"availabilityImpact\": \"LOW\"}, \"exploitabilityScore\": 2.8, \"impactScore\": 3.4}]}",
      "published": "2024-05-20T10:15:11.860",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Awaiting Analysis"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-35970\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-05-20T10:15:11.860\",\"lastModified\":\"2025-04-04T14:45:14.893\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\naf_unix: Clear stale u-\u003eoob_skb.\\n\\nsyzkaller started to report deadlock of unix_gc_lock after commit\\n4090fa373f0e (\\\"af_unix: Replace garbage collection algorithm.\\\"), but\\nit just uncovers the bug that has been there since commit 314001f0bf92\\n(\\\"af_unix: Add OOB support\\\").\\n\\nThe repro basically does the following.\\n\\n  from socket import *\\n  from array import array\\n\\n  c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)\\n  c1.sendmsg([b\u0027a\u0027], [(SOL_SOCKET, SCM_RIGHTS, array(\\\"i\\\", [c2.fileno()]))], MSG_OOB)\\n  c2.recv(1)  # blocked as no normal data in recv queue\\n\\n  c2.close()  # done async and unblock recv()\\n  c1.close()  # done async and trigger GC\\n\\nA socket sends its file descriptor to itself as OOB data and tries to\\nreceive normal data, but finally recv() fails due to async close().\\n\\nThe problem here is wrong handling of OOB skb in manage_oob().  When\\nrecvmsg() is called without MSG_OOB, manage_oob() is called to check\\nif the peeked skb is OOB skb.  In such a case, manage_oob() pops it\\nout of the receive queue but does not clear unix_sock(sk)-\u003eoob_skb.\\nThis is wrong in terms of uAPI.\\n\\nLet\u0027s say we send \\\"hello\\\" with MSG_OOB, and \\\"world\\\" without MSG_OOB.\\nThe \u0027o\u0027 is handled as OOB data.  When recv() is called twice without\\nMSG_OOB, the OOB data should be lost.\\n\\n  \u003e\u003e\u003e from socket import *\\n  \u003e\u003e\u003e c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)\\n  \u003e\u003e\u003e c1.send(b\u0027hello\u0027, MSG_OOB)  # \u0027o\u0027 is OOB data\\n  5\\n  \u003e\u003e\u003e c1.send(b\u0027world\u0027)\\n  5\\n  \u003e\u003e\u003e c2.recv(5)  # OOB data is not received\\n  b\u0027hell\u0027\\n  \u003e\u003e\u003e c2.recv(5)  # OOB date is skipped\\n  b\u0027world\u0027\\n  \u003e\u003e\u003e c2.recv(5, MSG_OOB)  # This should return an error\\n  b\u0027o\u0027\\n\\nIn the same situation, TCP actually returns -EINVAL for the last\\nrecv().\\n\\nAlso, if we do not clear unix_sk(sk)-\u003eoob_skb, unix_poll() always set\\nEPOLLPRI even though the data has passed through by previous recv().\\n\\nTo avoid these issues, we must clear unix_sk(sk)-\u003eoob_skb when dequeuing\\nit from recv queue.\\n\\nThe reason why the old GC did not trigger the deadlock is because the\\nold GC relied on the receive queue to detect the loop.\\n\\nWhen it is triggered, the socket with OOB data is marked as GC candidate\\nbecause file refcount == inflight count (1).  However, after traversing\\nall inflight sockets, the socket still has a positive inflight count (1),\\nthus the socket is excluded from candidates.  Then, the old GC lose the\\nchance to garbage-collect the socket.\\n\\nWith the old GC, the repro continues to create true garbage that will\\nnever be freed nor detected by kmemleak as it\u0027s linked to the global\\ninflight list.  That\u0027s why we couldn\u0027t even notice the issue.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Borrar u-\u0026gt;oob_skb obsoleto. syzkaller comenz\u00f3 a informar un punto muerto de unix_gc_lock despu\u00e9s de la confirmaci\u00f3n 4090fa373f0e (\\\"af_unix: Reemplazar el algoritmo de recolecci\u00f3n de basura\\\"), pero simplemente descubre el error que ha estado ah\u00ed desde la confirmaci\u00f3n 314001f0bf92 (\\\"af_unix: Agregar soporte OOB\\\"). La reproducci\u00f3n b\u00e1sicamente hace lo siguiente. desde importaci\u00f3n de socket * desde matriz de importaci\u00f3n matriz c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b\u0027a\u0027], [(SOL_SOCKET, SCM_RIGHTS, array(\\\"i\\\", [c2.fileno()])) ], MSG_OOB) c2.recv(1) # bloqueado porque no hay datos normales en la cola de recepci\u00f3n c2.close() # hecho as\u00edncrono y desbloquea recv() c1.close() # hecho as\u00edncrono y activa GC Un socket env\u00eda su descriptor de archivo a como datos OOB e intenta recibir datos normales, pero finalmente recv() falla debido al cierre as\u00edncrono(). El problema aqu\u00ed es el manejo incorrecto de OOB skb en Manage_oob(). Cuando se llama a recvmsg() sin MSG_OOB, se llama a Manage_oob() para verificar si el skb visto es skb OOB. En tal caso, Manage_oob() lo saca de la cola de recepci\u00f3n pero no borra unix_sock(sk)-\u0026gt;oob_skb. Esto est\u00e1 mal en t\u00e9rminos de uAPI. Digamos que enviamos \\\"hola\\\" con MSG_OOB y \\\"mundo\\\" sin MSG_OOB. La \u0027o\u0027 se maneja como datos OOB. Cuando se llama a recv() dos veces sin MSG_OOB, los datos OOB deber\u00edan perderse. \u0026gt;\u0026gt;\u0026gt; desde importaci\u00f3n de socket * \u0026gt;\u0026gt;\u0026gt; c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) \u0026gt;\u0026gt;\u0026gt; c1.send(b\u0027hello\u0027, MSG_OOB) # \u0027o\u0027 son datos OOB 5 \u0026gt;\u0026gt;\u0026gt; c1.send (b\u0027world\u0027) 5 \u0026gt;\u0026gt;\u0026gt; c2.recv(5) # Los datos OOB no se reciben b\u0027hell\u0027 \u0026gt;\u0026gt;\u0026gt; c2.recv(5) # La fecha OOB se omite b\u0027world\u0027 \u0026gt;\u0026gt;\u0026gt; c2.recv (5, MSG_OOB) # Esto deber\u00eda devolver un error b\u0027o\u0027. En la misma situaci\u00f3n, TCP en realidad devuelve -EINVAL para el \u00faltimo recv(). Adem\u00e1s, si no borramos unix_sk(sk)-\u0026gt;oob_skb, unix_poll() siempre establece EPOLLPRI aunque los datos hayan pasado por el recv() anterior. Para evitar estos problemas, debemos borrar unix_sk(sk)-\u0026gt;oob_skb al retirarlo de la cola de recepci\u00f3n. La raz\u00f3n por la que el antiguo GC no provoc\u00f3 el punto muerto es porque el antiguo GC depend\u00eda de la cola de recepci\u00f3n para detectar el bucle. Cuando se activa, el socket con datos OOB se marca como candidato de GC porque el recuento de archivos == recuento en vuelo (1). Sin embargo, despu\u00e9s de atravesar todos los sockets en vuelo, el socket todav\u00eda tiene un recuento positivo en vuelo (1), por lo que el socket queda excluido de los candidatos. Entonces, el antiguo GC pierde la oportunidad de recolectar basura en el socket. Con el antiguo GC, la reproducci\u00f3n contin\u00faa creando verdadera basura que kmemleak nunca liberar\u00e1 ni detectar\u00e1, ya que est\u00e1 vinculada a la lista global a bordo. Por eso ni siquiera pudimos notar el problema.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L\",\"baseScore\":6.3,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"LOW\",\"integrityImpact\":\"LOW\",\"availabilityImpact\":\"LOW\"},\"exploitabilityScore\":2.8,\"impactScore\":3.4}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-667\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.15\",\"versionEndExcluding\":\"5.15.156\",\"matchCriteriaId\":\"0A40A9D8-C388-43D1-AA37-C61111EB1774\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.87\",\"matchCriteriaId\":\"BDA59296-EDB8-44CD-98E4-C08C051569E6\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.28\",\"matchCriteriaId\":\"8D6315B0-B3BA-406C-B0DB-51D9A63753F0\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.8.7\",\"matchCriteriaId\":\"531BDFB5-EF6A-4707-902E-146368303499\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.9:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"22BEDD49-2C6D-402D-9DBF-6646F6ECD10B\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.9:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"DF73CB2A-DFFD-46FB-9BFE-AA394F27EA37\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.9:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"52048DDA-FC5A-4363-95A0-A6357B4D7F8C\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e\", \"tags\": [\"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-02T03:21:49.053Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 6.3, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L\", \"integrityImpact\": \"LOW\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"LOW\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"LOW\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2024-35970\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-05-20T14:23:05.468197Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"description\": \"CWE-noinfo Not enough information\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-05-23T19:01:24.840Z\"}}], \"cna\": {\"title\": \"af_unix: Clear stale u-\u003eoob_skb.\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"314001f0bf927015e459c9d387d62a231fe93af3\", \"lessThan\": \"b4bc99d04c689b5652665394ae8d3e02fb754153\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"314001f0bf927015e459c9d387d62a231fe93af3\", \"lessThan\": \"84a352b7eba1142a95441380058985ff19f25ec9\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"314001f0bf927015e459c9d387d62a231fe93af3\", \"lessThan\": \"601a89ea24d05089debfa2dc896ea9f5937ac7a6\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"314001f0bf927015e459c9d387d62a231fe93af3\", \"lessThan\": \"698a95ade1a00e6494482046902b986dfffd1caf\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"314001f0bf927015e459c9d387d62a231fe93af3\", \"lessThan\": \"b46f4eaa4f0ec38909fb0072eea3aeddb32f954e\", \"versionType\": \"git\"}], \"programFiles\": [\"net/unix/af_unix.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.15\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"5.15\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"5.15.156\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.15.*\"}, {\"status\": \"unaffected\", \"version\": \"6.1.87\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.1.*\"}, {\"status\": \"unaffected\", \"version\": \"6.6.28\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.6.*\"}, {\"status\": \"unaffected\", \"version\": \"6.8.7\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.8.*\"}, {\"status\": \"unaffected\", \"version\": \"6.9\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"net/unix/af_unix.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153\"}, {\"url\": \"https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9\"}, {\"url\": \"https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6\"}, {\"url\": \"https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf\"}, {\"url\": \"https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\naf_unix: Clear stale u-\u003eoob_skb.\\n\\nsyzkaller started to report deadlock of unix_gc_lock after commit\\n4090fa373f0e (\\\"af_unix: Replace garbage collection algorithm.\\\"), but\\nit just uncovers the bug that has been there since commit 314001f0bf92\\n(\\\"af_unix: Add OOB support\\\").\\n\\nThe repro basically does the following.\\n\\n  from socket import *\\n  from array import array\\n\\n  c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)\\n  c1.sendmsg([b\u0027a\u0027], [(SOL_SOCKET, SCM_RIGHTS, array(\\\"i\\\", [c2.fileno()]))], MSG_OOB)\\n  c2.recv(1)  # blocked as no normal data in recv queue\\n\\n  c2.close()  # done async and unblock recv()\\n  c1.close()  # done async and trigger GC\\n\\nA socket sends its file descriptor to itself as OOB data and tries to\\nreceive normal data, but finally recv() fails due to async close().\\n\\nThe problem here is wrong handling of OOB skb in manage_oob().  When\\nrecvmsg() is called without MSG_OOB, manage_oob() is called to check\\nif the peeked skb is OOB skb.  In such a case, manage_oob() pops it\\nout of the receive queue but does not clear unix_sock(sk)-\u003eoob_skb.\\nThis is wrong in terms of uAPI.\\n\\nLet\u0027s say we send \\\"hello\\\" with MSG_OOB, and \\\"world\\\" without MSG_OOB.\\nThe \u0027o\u0027 is handled as OOB data.  When recv() is called twice without\\nMSG_OOB, the OOB data should be lost.\\n\\n  \u003e\u003e\u003e from socket import *\\n  \u003e\u003e\u003e c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)\\n  \u003e\u003e\u003e c1.send(b\u0027hello\u0027, MSG_OOB)  # \u0027o\u0027 is OOB data\\n  5\\n  \u003e\u003e\u003e c1.send(b\u0027world\u0027)\\n  5\\n  \u003e\u003e\u003e c2.recv(5)  # OOB data is not received\\n  b\u0027hell\u0027\\n  \u003e\u003e\u003e c2.recv(5)  # OOB date is skipped\\n  b\u0027world\u0027\\n  \u003e\u003e\u003e c2.recv(5, MSG_OOB)  # This should return an error\\n  b\u0027o\u0027\\n\\nIn the same situation, TCP actually returns -EINVAL for the last\\nrecv().\\n\\nAlso, if we do not clear unix_sk(sk)-\u003eoob_skb, unix_poll() always set\\nEPOLLPRI even though the data has passed through by previous recv().\\n\\nTo avoid these issues, we must clear unix_sk(sk)-\u003eoob_skb when dequeuing\\nit from recv queue.\\n\\nThe reason why the old GC did not trigger the deadlock is because the\\nold GC relied on the receive queue to detect the loop.\\n\\nWhen it is triggered, the socket with OOB data is marked as GC candidate\\nbecause file refcount == inflight count (1).  However, after traversing\\nall inflight sockets, the socket still has a positive inflight count (1),\\nthus the socket is excluded from candidates.  Then, the old GC lose the\\nchance to garbage-collect the socket.\\n\\nWith the old GC, the repro continues to create true garbage that will\\nnever be freed nor detected by kmemleak as it\u0027s linked to the global\\ninflight list.  That\u0027s why we couldn\u0027t even notice the issue.\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.15.156\", \"versionStartIncluding\": \"5.15\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.1.87\", \"versionStartIncluding\": \"5.15\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.6.28\", \"versionStartIncluding\": \"5.15\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.8.7\", \"versionStartIncluding\": \"5.15\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.9\", \"versionStartIncluding\": \"5.15\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-05-04T09:09:29.452Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-35970\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-05-04T09:09:29.452Z\", \"dateReserved\": \"2024-05-17T13:50:33.141Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-05-20T09:41:58.524Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.