Skip to content
Heist/ feed
Back to feed
MediumFix available

af_unix: Clear stale u->oob_skb.

Type: advisorySources: OSV

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' >>

Products
Kernel
Affected versions
Not specified
Fixed versions
5.15.156, 6.1.87, 6.6.28, 6.8.7
CVEs
CVE-2024-35970
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 11:50 UTC · Revision 1

Source evidence

af_unix: Clear stale u->oob_skb.

core-osv · Original source

Published 20 May 2024, 09:41 UTC

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' >>

osv:CVE-2024-35970

Kernel

Fixed versions: 5.15.156, 6.1.87, 6.6.28, 6.8.7

Complete source record
{
  "id": "e4e82c94a54d94eb1825af3aa286aead8d7b1c96086ce30ac9a79e245f23c04b",
  "url": "https://osv.dev/vulnerability/CVE-2024-35970",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "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' >>",
    "evidence": "osv:CVE-2024-35970",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "5.15.156",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.1.87",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.6.28",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.8.7",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "medium",
    "structured": {
      "id": "CVE-2024-35970",
      "aliases": [
        "A-432804305",
        "ASB-A-432804305",
        "CVE-2024-35970"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "314001f0bf927015e459c9d387d62a231fe93af3"
                },
                {
                  "fixed": "b4bc99d04c689b5652665394ae8d3e02fb754153"
                },
                {
                  "fixed": "84a352b7eba1142a95441380058985ff19f25ec9"
                },
                {
                  "fixed": "601a89ea24d05089debfa2dc896ea9f5937ac7a6"
                },
                {
                  "fixed": "698a95ade1a00e6494482046902b986dfffd1caf"
                },
                {
                  "fixed": "b46f4eaa4f0ec38909fb0072eea3aeddb32f954e"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-35970.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.15.0"
                },
                {
                  "fixed": "5.15.156"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.16.0"
                },
                {
                  "fixed": "6.1.87"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.2.0"
                },
                {
                  "fixed": "6.6.28"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.8.7"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-35970.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:35.315125865Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6",
        "https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf",
        "https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9",
        "https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e",
        "https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/35xxx/CVE-2024-35970.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2024-35970",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/35xxx/CVE-2024-35970.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2024-35970",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 502176,
  "published_at": "2024-05-20T09:41:58.524+00:00"
}