GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GSD-2024-26624

Vulnerability from gsd - Updated: 2024-02-20 06:02
Details
In the Linux kernel, the following vulnerability has been resolved: af_unix: fix lockdep positive in sk_diag_dump_icons() syzbot reported a lockdep splat [1]. Blamed commit hinted about the possible lockdep violation, and code used unix_state_lock_nested() in an attempt to silence lockdep. It is not sufficient, because unix_state_lock_nested() is already used from unix_state_double_lock(). We need to use a separate subclass. This patch adds a distinct enumeration to make things more explicit. Also use swap() in unix_state_double_lock() as a clean up. v2: add a missing inline keyword to unix_state_lock_nested() [1] WARNING: possible circular locking dependency detected 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 Not tainted syz-executor.1/2542 is trying to acquire lock: ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, at: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 but task is already holding lock: ffff88808b5dfe70 (&u->lock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&u->lock/1){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378 sk_diag_dump_icons net/unix/diag.c:87 [inline] sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157 sk_diag_dump net/unix/diag.c:196 [inline] unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220 netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319 sock_diag_rcv_msg+0xe3/0x400 netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x39a/0x520 net/socket.c:1160 call_write_iter include/linux/fs.h:2085 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa74/0xca0 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b -> #0 (rlock-AF_UNIX){+.+.}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x592/0x890 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724 __do_sys_sendmmsg net/socket.c:2753 [inline] __se_sys_sendmmsg net/socket.c:2750 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---truncated---
Aliases

{
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2024-26624"
      ],
      "details": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: fix lockdep positive in sk_diag_dump_icons()\n\nsyzbot reported a lockdep splat [1].\n\nBlamed commit hinted about the possible lockdep\nviolation, and code used unix_state_lock_nested()\nin an attempt to silence lockdep.\n\nIt is not sufficient, because unix_state_lock_nested()\nis already used from unix_state_double_lock().\n\nWe need to use a separate subclass.\n\nThis patch adds a distinct enumeration to make things\nmore explicit.\n\nAlso use swap() in unix_state_double_lock() as a clean up.\n\nv2: add a missing inline keyword to unix_state_lock_nested()\n\n[1]\nWARNING: possible circular locking dependency detected\n6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 Not tainted\n\nsyz-executor.1/2542 is trying to acquire lock:\n ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, at: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863\n\nbut task is already holding lock:\n ffff88808b5dfe70 (\u0026u-\u003elock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (\u0026u-\u003elock/1){+.+.}-{2:2}:\n        lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n        _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378\n        sk_diag_dump_icons net/unix/diag.c:87 [inline]\n        sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157\n        sk_diag_dump net/unix/diag.c:196 [inline]\n        unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220\n        netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264\n        __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370\n        netlink_dump_start include/linux/netlink.h:338 [inline]\n        unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319\n       sock_diag_rcv_msg+0xe3/0x400\n        netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543\n        sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280\n        netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n        netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367\n        netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908\n        sock_sendmsg_nosec net/socket.c:730 [inline]\n        __sock_sendmsg net/socket.c:745 [inline]\n        sock_write_iter+0x39a/0x520 net/socket.c:1160\n        call_write_iter include/linux/fs.h:2085 [inline]\n        new_sync_write fs/read_write.c:497 [inline]\n        vfs_write+0xa74/0xca0 fs/read_write.c:590\n        ksys_write+0x1a0/0x2c0 fs/read_write.c:643\n        do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n        do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83\n       entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\n-\u003e #0 (rlock-AF_UNIX){+.+.}-{2:2}:\n        check_prev_add kernel/locking/lockdep.c:3134 [inline]\n        check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n        validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869\n        __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n        lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n        __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n        _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162\n        skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863\n        unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112\n        sock_sendmsg_nosec net/socket.c:730 [inline]\n        __sock_sendmsg net/socket.c:745 [inline]\n        ____sys_sendmsg+0x592/0x890 net/socket.c:2584\n        ___sys_sendmsg net/socket.c:2638 [inline]\n        __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724\n        __do_sys_sendmmsg net/socket.c:2753 [inline]\n        __se_sys_sendmmsg net/socket.c:2750 [inline]\n        __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750\n        do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n        do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83\n       entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n       CPU0             \n---truncated---",
      "id": "GSD-2024-26624",
      "modified": "2024-02-20T06:02:29.197709Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "cve@kernel.org",
        "ID": "CVE-2024-26624",
        "STATE": "REJECT"
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
          }
        ]
      }
    },
    "nvd.nist.gov": {
      "cve": {
        "descriptions": [
          {
            "lang": "en",
            "value": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
          }
        ],
        "id": "CVE-2024-26624",
        "lastModified": "2024-03-27T14:15:10.163",
        "metrics": {},
        "published": "2024-03-06T07:15:12.360",
        "references": [],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Rejected"
      }
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…