Common Weakness Enumeration

CWE-667

Allowed-with-Review

Improper Locking

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

713 vulnerabilities reference this CWE, most recent first.

GHSA-GV5W-824R-R7XX

Vulnerability from github – Published: 2024-05-19 09:34 – Updated: 2025-09-19 21:31
VLAI
Details

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

net/sched: fix lockdep splat in qdisc_tree_reduce_backlog()

qdisc_tree_reduce_backlog() is called with the qdisc lock held, not RTNL.

We must use qdisc_lookup_rcu() instead of qdisc_lookup()

syzbot reported:

WARNING: suspicious RCU usage 6.1.74-syzkaller #0 Not tainted

net/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1 3 locks held by udevd/1142: #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282 #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline] #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297 #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792

stack backtrace: CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: [] __dump_stack lib/dump_stack.c:88 [inline] [] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106 [] dump_stack+0x15/0x1e lib/dump_stack.c:113 [] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592 [] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305 [] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811 [] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51 [] qdisc_enqueue include/net/sch_generic.h:833 [inline] [] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723 [] dequeue_skb net/sched/sch_generic.c:292 [inline] [] qdisc_restart net/sched/sch_generic.c:397 [inline] [] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415 [] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125 [] net_tx_action+0x7c9/0x970 net/core/dev.c:5313 [] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616 [] invoke_softirq kernel/softirq.c:447 [inline] [] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700 [] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712 [] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-35892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-19T09:15:10Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix lockdep splat in qdisc_tree_reduce_backlog()\n\nqdisc_tree_reduce_backlog() is called with the qdisc lock held,\nnot RTNL.\n\nWe must use qdisc_lookup_rcu() instead of qdisc_lookup()\n\nsyzbot reported:\n\nWARNING: suspicious RCU usage\n6.1.74-syzkaller #0 Not tainted\n-----------------------------\nnet/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n3 locks held by udevd/1142:\n  #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]\n  #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]\n  #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282\n  #1: ffff888171861108 (\u0026sch-\u003eq.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline]\n  #1: ffff888171861108 (\u0026sch-\u003eq.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297\n  #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]\n  #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]\n  #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792\n\nstack backtrace:\nCPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall Trace:\n \u003cTASK\u003e\n  [\u003cffffffff85b85f14\u003e] __dump_stack lib/dump_stack.c:88 [inline]\n  [\u003cffffffff85b85f14\u003e] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106\n  [\u003cffffffff85b86007\u003e] dump_stack+0x15/0x1e lib/dump_stack.c:113\n  [\u003cffffffff81802299\u003e] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592\n  [\u003cffffffff84f0054c\u003e] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305\n  [\u003cffffffff84f037c3\u003e] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811\n  [\u003cffffffff84f5b78c\u003e] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51\n  [\u003cffffffff84fbcf63\u003e] qdisc_enqueue include/net/sch_generic.h:833 [inline]\n  [\u003cffffffff84fbcf63\u003e] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723\n  [\u003cffffffff84eecab9\u003e] dequeue_skb net/sched/sch_generic.c:292 [inline]\n  [\u003cffffffff84eecab9\u003e] qdisc_restart net/sched/sch_generic.c:397 [inline]\n  [\u003cffffffff84eecab9\u003e] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415\n  [\u003cffffffff84d7aa96\u003e] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125\n  [\u003cffffffff84d85d29\u003e] net_tx_action+0x7c9/0x970 net/core/dev.c:5313\n  [\u003cffffffff85e002bd\u003e] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616\n  [\u003cffffffff81568bca\u003e] invoke_softirq kernel/softirq.c:447 [inline]\n  [\u003cffffffff81568bca\u003e] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700\n  [\u003cffffffff81568ae9\u003e] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712\n  [\u003cffffffff85b89f52\u003e] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107\n  [\u003cffffffff85c00ccb\u003e] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656",
  "id": "GHSA-gv5w-824r-r7xx",
  "modified": "2025-09-19T21:31:15Z",
  "published": "2024-05-19T09:34:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35892"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07696415526bee0607e495017369c7303a4792e1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7eb322360b0266481e560d1807ee79e0cef5742b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b7d1ce2cc7192e8a037faa3f5d3ba72c25976460"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c040b99461a5bfc14c2d0cbb1780fcc3a4706c7e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GV6C-55WW-R8WV

Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2025-09-25 18:30
VLAI
Details

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

ext4: fix racy may inline data check in dio write

syzbot reports that the following warning from ext4_iomap_begin() triggers as of the commit referenced below:

    if (WARN_ON_ONCE(ext4_has_inline_data(inode)))
            return -ERANGE;

This occurs during a dio write, which is never expected to encounter an inode with inline data. To enforce this behavior, ext4_dio_write_iter() checks the current inline state of the inode and clears the MAY_INLINE_DATA state flag to either fall back to buffered writes, or enforce that any other writers in progress on the inode are not allowed to create inline data.

The problem is that the check for existing inline data and the state flag can span a lock cycle. For example, if the ilock is originally locked shared and subsequently upgraded to exclusive, another writer may have reacquired the lock and created inline data before the dio write task acquires the lock and proceeds.

The commit referenced below loosens the lock requirements to allow some forms of unaligned dio writes to occur under shared lock, but AFAICT the inline data check was technically already racy for any dio write that would have involved a lock cycle. Regardless, lift clearing of the state bit to the same lock critical section that checks for preexisting inline data on the inode to close the race.

Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-52786"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T16:15:17Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix racy may inline data check in dio write\n\nsyzbot reports that the following warning from ext4_iomap_begin()\ntriggers as of the commit referenced below:\n\n        if (WARN_ON_ONCE(ext4_has_inline_data(inode)))\n                return -ERANGE;\n\nThis occurs during a dio write, which is never expected to encounter\nan inode with inline data. To enforce this behavior,\next4_dio_write_iter() checks the current inline state of the inode\nand clears the MAY_INLINE_DATA state flag to either fall back to\nbuffered writes, or enforce that any other writers in progress on\nthe inode are not allowed to create inline data.\n\nThe problem is that the check for existing inline data and the state\nflag can span a lock cycle. For example, if the ilock is originally\nlocked shared and subsequently upgraded to exclusive, another writer\nmay have reacquired the lock and created inline data before the dio\nwrite task acquires the lock and proceeds.\n\nThe commit referenced below loosens the lock requirements to allow\nsome forms of unaligned dio writes to occur under shared lock, but\nAFAICT the inline data check was technically already racy for any\ndio write that would have involved a lock cycle. Regardless, lift\nclearing of the state bit to the same lock critical section that\nchecks for preexisting inline data on the inode to close the race.",
  "id": "GHSA-gv6c-55ww-r8wv",
  "modified": "2025-09-25T18:30:28Z",
  "published": "2024-05-21T18:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52786"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GVMP-GR98-MP6J

Vulnerability from github – Published: 2022-04-29 02:57 – Updated: 2024-02-15 21:31
VLAI
Details

Apache 1.4.x before 1.3.30, and 2.0.x before 2.0.49, when using multiple listening sockets on certain platforms, allows remote attackers to cause a denial of service (blocked new connections) via a "short-lived connection on a rarely-accessed listening socket."

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2004-0174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2004-05-04T04:00:00Z",
    "severity": "MODERATE"
  },
  "details": "Apache 1.4.x before 1.3.30, and 2.0.x before 2.0.49, when using multiple listening sockets on certain platforms, allows remote attackers to cause a denial of service (blocked new connections) via a \"short-lived connection on a rarely-accessed listening socket.\"",
  "id": "GHSA-gvmp-gr98-mp6j",
  "modified": "2024-02-15T21:31:23Z",
  "published": "2022-04-29T02:57:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2004-0174"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9e8622254184645bc963a1d47c5d47f6d5a36d6f080d8d2c43b2b142%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9e8622254184645bc963a1d47c5d47f6d5a36d6f080d8d2c43b2b142@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/raa117ef183f0da9b3f46efbeaa66f7622bd68868a450cae4fd8ed594%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/raa117ef183f0da9b3f46efbeaa66f7622bd68868a450cae4fd8ed594@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd65d8ba68ba17e7deedafbf5bb4899f2ae4dad781d21b931c2941ac3%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd65d8ba68ba17e7deedafbf5bb4899f2ae4dad781d21b931c2941ac3@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re895fc1736d25c8cf57e102c871613b8aeec9ea26fd8a44e7942b5ab%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re895fc1736d25c8cf57e102c871613b8aeec9ea26fd8a44e7942b5ab@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf2f0f3611f937cf6cfb3b4fe4a67f69885855126110e1e3f2fb2728e%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf2f0f3611f937cf6cfb3b4fe4a67f69885855126110e1e3f2fb2728e@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A100110"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A1982"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/15540"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/54a42d4b01968df1117cea77fc53d6beb931c0e05936ad02af93e9ac%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/54a42d4b01968df1117cea77fc53d6beb931c0e05936ad02af93e9ac@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/5df9bfb86a3b054bb985a45ff9250b0332c9ecc181eec232489e7f79%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/5df9bfb86a3b054bb985a45ff9250b0332c9ecc181eec232489e7f79@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0276683d8e1e07153fc8642618830ac0ade85b9ae0dc7b07f63bb8fc%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0276683d8e1e07153fc8642618830ac0ade85b9ae0dc7b07f63bb8fc@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2cb985de917e7da0848c440535f65a247754db8b2154a10089e4247b%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2cb985de917e7da0848c440535f65a247754db8b2154a10089e4247b@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5001ecf3d6b2bdd0b732e527654248abb264f08390045d30709a92f6%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5001ecf3d6b2bdd0b732e527654248abb264f08390045d30709a92f6@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5419c9ba0951ef73a655362403d12bb8d10fab38274deb3f005816f5%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5419c9ba0951ef73a655362403d12bb8d10fab38274deb3f005816f5@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5f9c22f9c28adbd9f00556059edc7b03a5d5bb71d4bb80257c0d34e4%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5f9c22f9c28adbd9f00556059edc7b03a5d5bb71d4bb80257c0d34e4@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8828e649175df56f1f9e3919938ac7826128525426e2748f0ab62feb%40%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8828e649175df56f1f9e3919938ac7826128525426e2748f0ab62feb@%3Ccvs.httpd.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=107973894328806\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=108066914830552\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=108369640424244\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=108437852004207\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=108731648532365\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/11170"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-200405-22.xml"
    },
    {
      "type": "WEB",
      "url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-101555-1"
    },
    {
      "type": "WEB",
      "url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-57628-1"
    },
    {
      "type": "WEB",
      "url": "http://www.apache.org/dist/httpd/CHANGES_1.3"
    },
    {
      "type": "WEB",
      "url": "http://www.kb.cert.org/vuls/id/132110"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDKSA-2004:046"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2004-405.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/9921"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/alerts/2004/Mar/1009495.html"
    },
    {
      "type": "WEB",
      "url": "http://www.slackware.com/security/viewer.php?l=slackware-security\u0026y=2004\u0026m=slackware-security.529643"
    },
    {
      "type": "WEB",
      "url": "http://www.trustix.org/errata/2004/0027"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GVXC-64WH-VGV2

Vulnerability from github – Published: 2024-04-10 21:30 – Updated: 2024-11-01 18:31
VLAI
Details

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

tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc

When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one:

Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120

In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it.

Severity
4.4 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-47185"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-10T19:15:47Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: tty_buffer: Fix the softlockup issue in flush_to_ldisc\n\nWhen running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,\nwhich look like this one:\n\n  Workqueue: events_unbound flush_to_ldisc\n  Call trace:\n   dump_backtrace+0x0/0x1ec\n   show_stack+0x24/0x30\n   dump_stack+0xd0/0x128\n   panic+0x15c/0x374\n   watchdog_timer_fn+0x2b8/0x304\n   __run_hrtimer+0x88/0x2c0\n   __hrtimer_run_queues+0xa4/0x120\n   hrtimer_interrupt+0xfc/0x270\n   arch_timer_handler_phys+0x40/0x50\n   handle_percpu_devid_irq+0x94/0x220\n   __handle_domain_irq+0x88/0xf0\n   gic_handle_irq+0x84/0xfc\n   el1_irq+0xc8/0x180\n   slip_unesc+0x80/0x214 [slip]\n   tty_ldisc_receive_buf+0x64/0x80\n   tty_port_default_receive_buf+0x50/0x90\n   flush_to_ldisc+0xbc/0x110\n   process_one_work+0x1d4/0x4b0\n   worker_thread+0x180/0x430\n   kthread+0x11c/0x120\n\nIn the testcase pty04, The first process call the write syscall to send\ndata to the pty master. At the same time, the workqueue will do the\nflush_to_ldisc to pop data in a loop until there is no more data left.\nWhen the sender and workqueue running in different core, the sender sends\ndata fastly in full time which will result in workqueue doing work in loop\nfor a long time and occuring softlockup in flush_to_ldisc with kernel\nconfigured without preempt. So I add need_resched check and cond_resched\nin the flush_to_ldisc loop to avoid it.",
  "id": "GHSA-gvxc-64wh-vgv2",
  "modified": "2024-11-01T18:31:25Z",
  "published": "2024-04-10T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47185"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0550a1c1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GWMF-R7M2-PPHM

Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-10 21:31
VLAI
Details

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

openvswitch: vport: fix self-deadlock on release of tunnel ports

vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. So, either in an RCU call or after the synchronize_net(). The rtnl_delete_link() must happen under RTNL and so can't be executed in RCU context. Calling synchronize_net() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdev_put() in RCU call is the right solution here.

However, when the device is deleted, rtnl_unlock() will call netdev_run_todo() and block until all the references are gone. In the current code this means that we never reach the call_rcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal.

Fix that by moving the rcu_call() before the rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself is already released.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-46165"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T10:16:32Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: vport: fix self-deadlock on release of tunnel ports\n\nvports are used concurrently and protected by RCU, so netdev_put()\nmust happen after the RCU grace period.  So, either in an RCU call or\nafter the synchronize_net().  The rtnl_delete_link() must happen under\nRTNL and so can\u0027t be executed in RCU context.  Calling synchronize_net()\nwhile holding RTNL is not a good idea for performance and system\nstability under load in general, so calling netdev_put() in RCU call\nis the right solution here.\n\nHowever,\nwhen the device is deleted, rtnl_unlock() will call netdev_run_todo()\nand block until all the references are gone.  In the current code this\nmeans that we never reach the call_rcu() and the vport is never freed\nand the reference is never released, causing a self-deadlock on device\nremoval.\n\nFix that by moving the rcu_call() before the rtnl_unlock(), so the\nscheduled RCU callback will be executed when synchronize_net() is\ncalled from the rtnl_unlock()-\u003enetdev_run_todo() while the RTNL itself\nis already released.",
  "id": "GHSA-gwmf-r7m2-pphm",
  "modified": "2026-06-10T21:31:25Z",
  "published": "2026-05-28T12:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46165"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/366c482965c673565ecb8bcfb15d5548f13a6a10"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3df75fff46b1517eb479d8e6b8e3500763715dd0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6522d59fb7de55ce0f0f285d962243ddffebb01f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8ae6c15fc473c9ad03b0173330cce9a092c76154"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aa69918bd418e700309fdd08509dba324fb24296"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c741433f6c8dcdecd1d9549d89053761fd1ea413"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GXG5-6XG7-GC7Q

Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-04-29 21:31
VLAI
Details

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

ALSA: timer: Don't take register_mutex with copy_from/to_user()

The infamous mmap_lock taken in copy_from/to_user() can be often problematic when it's called inside another mutex, as they might lead to deadlocks.

In the case of ALSA timer code, the bad pattern is with guard(mutex)(&register_mutex) that covers copy_from/to_user() -- which was mistakenly introduced at converting to guard(), and it had been carefully worked around in the past.

This patch fixes those pieces simply by moving copy_from/to_user() out of the register mutex lock again.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-23134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-16T15:16:07Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: timer: Don\u0027t take register_mutex with copy_from/to_user()\n\nThe infamous mmap_lock taken in copy_from/to_user() can be often\nproblematic when it\u0027s called inside another mutex, as they might lead\nto deadlocks.\n\nIn the case of ALSA timer code, the bad pattern is with\nguard(mutex)(\u0026register_mutex) that covers copy_from/to_user() -- which\nwas mistakenly introduced at converting to guard(), and it had been\ncarefully worked around in the past.\n\nThis patch fixes those pieces simply by moving copy_from/to_user() out\nof the register mutex lock again.",
  "id": "GHSA-gxg5-6xg7-gc7q",
  "modified": "2025-04-29T21:31:48Z",
  "published": "2025-04-16T15:34:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23134"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/15291b561d8cc835a2eea76b394070cf8e072771"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/296f7a9e15aab276db11206cbc1e2ae1215d7862"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3424c8f53bc63c87712a7fc22dc13d0cc85fb0d6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b074f47e55df93832bbbca1b524c501e6fea1c0d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H343-797X-8CG9

Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-10 00:30
VLAI
Details

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

sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop

With this refcnt added in sctp_stream_priorities, we don't need to traverse all streams to check if the prio is used by other streams when freeing one stream's prio in sctp_sched_prio_free_sid(). This can avoid a nested loop (up to 65535 * 65535), which may cause a stuck as Ying reported:

watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]
Call Trace:
 <TASK>
 sctp_sched_prio_free_sid+0xab/0x100 [sctp]
 sctp_stream_free_ext+0x64/0xa0 [sctp]
 sctp_stream_free+0x31/0x50 [sctp]
 sctp_association_free+0xa5/0x200 [sctp]

Note that it doesn't need to use refcount_t type for this counter, as its accessing is always protected under the sock lock.

v1->v2: - add a check in sctp_sched_prio_set to avoid the possible prio_head refcnt overflow.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-53590"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-04T16:15:55Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: add a refcnt in sctp_stream_priorities to avoid a nested loop\n\nWith this refcnt added in sctp_stream_priorities, we don\u0027t need to\ntraverse all streams to check if the prio is used by other streams\nwhen freeing one stream\u0027s prio in sctp_sched_prio_free_sid(). This\ncan avoid a nested loop (up to 65535 * 65535), which may cause a\nstuck as Ying reported:\n\n    watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]\n    Call Trace:\n     \u003cTASK\u003e\n     sctp_sched_prio_free_sid+0xab/0x100 [sctp]\n     sctp_stream_free_ext+0x64/0xa0 [sctp]\n     sctp_stream_free+0x31/0x50 [sctp]\n     sctp_association_free+0xa5/0x200 [sctp]\n\nNote that it doesn\u0027t need to use refcount_t type for this counter,\nas its accessing is always protected under the sock lock.\n\nv1-\u003ev2:\n - add a check in sctp_sched_prio_set to avoid the possible prio_head\n   refcnt overflow.",
  "id": "GHSA-h343-797x-8cg9",
  "modified": "2026-02-10T00:30:28Z",
  "published": "2025-10-04T18:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53590"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/03c3a5584a0a29821e59b7834635ce823050caaa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/68ba44639537de6f91fe32783766322d41848127"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6d529928ea212127851a2df8c40d822237ca946b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8ee401f89cdb10f39098c0656d695b2bc4052100"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bf5540cbd20e2dae2c81ab9b31deef41ef147d0a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cec326443f01283ef68ea00c06ea073b1835a562"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H365-5RJ6-9GJ5

Vulnerability from github – Published: 2024-10-21 15:32 – Updated: 2026-05-12 12:32
VLAI
Details

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

RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled

Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold.

This was discovered through the lock debugging, and the corresponding log is as follows:

raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-47735"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T13:15:03Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled\n\nFix missuse of spin_lock_irq()/spin_unlock_irq() when\nspin_lock_irqsave()/spin_lock_irqrestore() was hold.\n\nThis was discovered through the lock debugging, and the corresponding\nlog is as follows:\n\nraw_local_irq_restore() called with IRQs enabled\nWARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40\n...\nCall trace:\n warn_bogus_irq_restore+0x30/0x40\n _raw_spin_unlock_irqrestore+0x84/0xc8\n add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]\n hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]\n hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]\n create_qp+0x138/0x258\n ib_create_qp_kernel+0x50/0xe8\n create_mad_qp+0xa8/0x128\n ib_mad_port_open+0x218/0x448\n ib_mad_init_device+0x70/0x1f8\n add_client_context+0xfc/0x220\n enable_device_and_get+0xd0/0x140\n ib_register_device.part.0+0xf4/0x1c8\n ib_register_device+0x34/0x50\n hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]\n hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]\n __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]\n hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]",
  "id": "GHSA-h365-5rj6-9gj5",
  "modified": "2026-05-12T12:32:10Z",
  "published": "2024-10-21T15:32:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07f0f643d7e570dbe8ef6f5c3367a43e3086a335"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/094a1821903f33fb91de4b71087773ee16aeb3a0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2656336a84fcb6802f6e6c233f4661891deea24f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/29c0f546d3fd66238b42cf25bcd5f193bb1cf794"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/425589d4af09c49574bd71ac31f811362a5126c3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/74d315b5af180220d561684d15897730135733a6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a1a3403bb1826c8ec787f0d60c3e7b54f419129e"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H3C3-PP9V-WF35

Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-11 21:31
VLAI
Details

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

mptcp: pm: in-kernel: always set ID as avail when rm endp

Syzkaller managed to find a combination of actions that was generating this warning:

WARNING: net/mptcp/pm_kernel.c:1074 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline], CPU#1: syz.7.48/2535 WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538, CPU#1: syz.7.48/2535 Modules linked in: CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e676cf5 #17 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline] RIP: 0010:mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538 Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 89 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 <0f> 0b 90 e9 3d ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89 RSP: 0018:ffffc9001535b820 EFLAGS: 00010287 netdevsim0: tun_chr_ioctl cmd 1074025677 RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7 netdevsim0: linktype set to 823 RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800 FS: 00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000000 netlink: 'syz.3.50': attribute type 5 has an invalid length. CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 netlink: 1232 bytes leftover after parsing attributes in process `syz.3.50'. CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0 Call Trace: mptcp_pm_set_flags net/mptcp/pm_netlink.c:277 [inline] mptcp_pm_nl_set_flags_doit+0x1d7/0x210 net/mptcp/pm_netlink.c:282 genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4ab/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:733 _syssendmsg+0x272/0x3b0 net/socket.c:2608 _sys_sendmsg+0x2de/0x320 net/socket.c:2662 __sys_sendmsg net/socket.c:2694 [inline] __do_sys_sendmsg net/socket.c:2699 [inline] __se_sys_sendmsg net/socket.c:2697 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2697 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xed/0x360 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc6adb66f6d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000 ---truncated---

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-43252"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-06T12:16:45Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: in-kernel: always set ID as avail when rm endp\n\nSyzkaller managed to find a combination of actions that was generating\nthis warning:\n\n  WARNING: net/mptcp/pm_kernel.c:1074 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline], CPU#1: syz.7.48/2535\n  WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline], CPU#1: syz.7.48/2535\n  WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline], CPU#1: syz.7.48/2535\n  WARNING: net/mptcp/pm_kernel.c:1074 at mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538, CPU#1: syz.7.48/2535\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 2535 Comm: syz.7.48 Not tainted 6.18.0-03987-gea5f5e676cf5 #17 PREEMPT(voluntary)\n  Hardware name: QEMU Ubuntu 25.10 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n  RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1074 [inline]\n  RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1446 [inline]\n  RIP: 0010:mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1474 [inline]\n  RIP: 0010:mptcp_pm_nl_set_flags+0x5de/0x640 net/mptcp/pm_kernel.c:1538\n  Code: 89 c7 e8 c5 8c 73 fe e9 f7 fd ff ff 49 83 ef 80 e8 b7 8c 73 fe 4c 89 ff be 03 00 00 00 e8 4a 29 e3 fe eb ac e8 a3 8c 73 fe 90 \u003c0f\u003e 0b 90 e9 3d ff ff ff e8 95 8c 73 fe b8 a1 ff ff ff eb 1a e8 89\n  RSP: 0018:ffffc9001535b820 EFLAGS: 00010287\n  netdevsim0: tun_chr_ioctl cmd 1074025677\n  RAX: ffffffff82da294d RBX: 0000000000000001 RCX: 0000000000080000\n  RDX: ffffc900096d0000 RSI: 00000000000006d6 RDI: 00000000000006d7\n  netdevsim0: linktype set to 823\n  RBP: ffff88802cdb2240 R08: 00000000000104ae R09: ffffffffffffffff\n  R10: ffffffff82da27d4 R11: 0000000000000000 R12: 0000000000000000\n  R13: ffff88801246d8c0 R14: ffffc9001535b8b8 R15: ffff88802cdb1800\n  FS:  00007fc6ac5a76c0(0000) GS:ffff8880f90c8000(0000) knlGS:0000000000000000\n  netlink: \u0027syz.3.50\u0027: attribute type 5 has an invalid length.\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  netlink: 1232 bytes leftover after parsing attributes in process `syz.3.50\u0027.\n  CR2: 0000200000010000 CR3: 0000000025b1a000 CR4: 0000000000350ef0\n  Call Trace:\n   \u003cTASK\u003e\n   mptcp_pm_set_flags net/mptcp/pm_netlink.c:277 [inline]\n   mptcp_pm_nl_set_flags_doit+0x1d7/0x210 net/mptcp/pm_netlink.c:282\n   genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115\n   genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n   genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210\n   netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550\n   genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n   netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]\n   netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344\n   netlink_sendmsg+0x4ab/0x5b0 net/netlink/af_netlink.c:1894\n   sock_sendmsg_nosec net/socket.c:718 [inline]\n   __sock_sendmsg+0xc9/0xf0 net/socket.c:733\n   ____sys_sendmsg+0x272/0x3b0 net/socket.c:2608\n   ___sys_sendmsg+0x2de/0x320 net/socket.c:2662\n   __sys_sendmsg net/socket.c:2694 [inline]\n   __do_sys_sendmsg net/socket.c:2699 [inline]\n   __se_sys_sendmsg net/socket.c:2697 [inline]\n   __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2697\n   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0xed/0x360 arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x7fc6adb66f6d\n  Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48\n  RSP: 002b:00007fc6ac5a6ff8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n  RAX: ffffffffffffffda RBX: 00007fc6addf5fa0 RCX: 00007fc6adb66f6d\n  RDX: 0000000000048084 RSI: 00002000000002c0 RDI: 000000000000000e\n  RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000\n---truncated---",
  "id": "GHSA-h3c3-pp9v-wf35",
  "modified": "2026-05-11T21:31:31Z",
  "published": "2026-05-06T12:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43252"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1b3ff4d88b508b73e2bbddb59356311efb7ba192"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4d480efd98e290c445f4ba476e4dcda5624b1aab"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7c1d221e475e3d8eb8ed4702392d43f8c5134d1f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7e4d88e36e5d0b8ffda637999cbca64c81701a81"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d191101dee25567c2af3b28565f45346c33d65f5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d90d73ad183566c81320d453a223f610a280f210"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H3CR-2X3P-H22W

Vulnerability from github – Published: 2023-05-15 09:30 – Updated: 2024-04-04 04:05
VLAI
Details

Denial of service in Webconf in Tribe29 Checkmk Appliance before 1.6.5.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-22318"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-412",
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-15T09:15:09Z",
    "severity": "HIGH"
  },
  "details": "Denial of service in Webconf in Tribe29 Checkmk Appliance before 1.6.5.",
  "id": "GHSA-h3cr-2x3p-h22w",
  "modified": "2024-04-04T04:05:02Z",
  "published": "2023-05-15T09:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22318"
    },
    {
      "type": "WEB",
      "url": "https://checkmk.com/werk/9526"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Implementation

Strategy: Libraries or Frameworks

Use industry standard APIs to implement locking mechanism.

CAPEC-25: Forced Deadlock

The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.

CAPEC-26: Leveraging Race Conditions

The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.

CAPEC-27: Leveraging Race Conditions via Symbolic Links

This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.

← Back to the CWE list