CWE-617
AllowedReachable Assertion
Abstraction: Base · Status: Draft
The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
989 vulnerabilities reference this CWE, most recent first.
GHSA-PH87-FVJR-V33W
Vulnerability from github – Published: 2021-05-21 14:25 – Updated: 2024-11-01 16:55Impact
An attacker can cause a denial of service by exploiting a CHECK-failure coming from the implementation of tf.raw_ops.RFFT:
import tensorflow as tf
inputs = tf.constant([1], shape=[1], dtype=tf.float32)
fft_length = tf.constant([0], shape=[1], dtype=tf.int32)
tf.raw_ops.RFFT(input=inputs, fft_length=fft_length)
The above example causes Eigen code to operate on an empty matrix. This triggers on an assertion and causes program termination.
Patches
We have patched the issue in GitHub commit 31bd5026304677faa8a0b77602c6154171b9aec1.
The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.
For more information
Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.
Attribution
This vulnerability has been reported by Yakun Zhang and Ying Wang of Baidu X-Team.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-29563"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-18T19:46:06Z",
"nvd_published_at": "2021-05-14T20:15:00Z",
"severity": "LOW"
},
"details": "### Impact\nAn attacker can cause a denial of service by exploiting a `CHECK`-failure coming from the implementation of `tf.raw_ops.RFFT`:\n \n```python\nimport tensorflow as tf\n\ninputs = tf.constant([1], shape=[1], dtype=tf.float32)\nfft_length = tf.constant([0], shape=[1], dtype=tf.int32)\n\ntf.raw_ops.RFFT(input=inputs, fft_length=fft_length)\n```\n\nThe above example causes Eigen code to operate on an empty matrix. This triggers on an assertion and causes program termination.\n \n### Patches\nWe have patched the issue in GitHub commit [31bd5026304677faa8a0b77602c6154171b9aec1](https://github.com/tensorflow/tensorflow/commit/31bd5026304677faa8a0b77602c6154171b9aec1).\n\nThe fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions. \n\n### Attribution\nThis vulnerability has been reported by Yakun Zhang and Ying Wang of Baidu X-Team.",
"id": "GHSA-ph87-fvjr-v33w",
"modified": "2024-11-01T16:55:05Z",
"published": "2021-05-21T14:25:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-ph87-fvjr-v33w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29563"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/31bd5026304677faa8a0b77602c6154171b9aec1"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-491.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-689.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-200.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorflow/tensorflow"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CHECK-fail in `tf.raw_ops.RFFT`"
}
GHSA-PM7P-WJQ9-6M43
Vulnerability from github – Published: 2025-08-16 12:30 – Updated: 2026-01-22 18:50In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix assertion when building free space tree
When building the free space tree with the block group tree feature enabled, we can hit an assertion failure like this:
BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]---
This happens because we are processing an empty block group, which has no extents allocated from it, there are no items for this block group, including the block group item since block group items are stored in a dedicated tree when using the block group tree feature. It also means this is the block group with the highest start offset, so there are no higher keys in the extent root, hence btrfs_search_slot_for_read() returns 1 (no higher key found).
Fix this by asserting 'ret' is 0 only if the block group tree feature is not enabled, in which case we should find a block group item for the block group since it's stored in the extent root and block group item keys are greater than extent item keys (the value for BTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and BTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively). In case 'ret' is 1, we just need to add a record to the free space tree which spans the whole block group, and we can achieve this by making 'ret == 0' as the while loop's condition.
{
"affected": [],
"aliases": [
"CVE-2025-38503"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-16T11:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix assertion when building free space tree\n\nWhen building the free space tree with the block group tree feature\nenabled, we can hit an assertion failure like this:\n\n BTRFS info (device loop0 state M): rebuilding free space tree\n assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102\n ------------[ cut here ]------------\n kernel BUG at fs/btrfs/free-space-tree.c:1102!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n Modules linked in:\n CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102\n lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102\n sp : ffff8000a4ce7600\n x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8\n x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001\n x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160\n x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff\n x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0\n x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff\n x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00\n x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001\n x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0\n x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e\n Call trace:\n populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P)\n btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337\n btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074\n btrfs_remount_rw fs/btrfs/super.c:1319 [inline]\n btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543\n reconfigure_super+0x1d4/0x6f0 fs/super.c:1083\n do_remount fs/namespace.c:3365 [inline]\n path_mount+0xb34/0xde0 fs/namespace.c:4200\n do_mount fs/namespace.c:4221 [inline]\n __do_sys_mount fs/namespace.c:4432 [inline]\n __se_sys_mount fs/namespace.c:4409 [inline]\n __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767\n el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n Code: f0047182 91178042 528089c3 9771d47b (d4210000)\n ---[ end trace 0000000000000000 ]---\n\nThis happens because we are processing an empty block group, which has\nno extents allocated from it, there are no items for this block group,\nincluding the block group item since block group items are stored in a\ndedicated tree when using the block group tree feature. It also means\nthis is the block group with the highest start offset, so there are no\nhigher keys in the extent root, hence btrfs_search_slot_for_read()\nreturns 1 (no higher key found).\n\nFix this by asserting \u0027ret\u0027 is 0 only if the block group tree feature\nis not enabled, in which case we should find a block group item for\nthe block group since it\u0027s stored in the extent root and block group\nitem keys are greater than extent item keys (the value for\nBTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and\nBTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).\nIn case \u0027ret\u0027 is 1, we just need to add a record to the free space\ntree which spans the whole block group, and we can achieve this by\nmaking \u0027ret == 0\u0027 as the while loop\u0027s condition.",
"id": "GHSA-pm7p-wjq9-6m43",
"modified": "2026-01-22T18:50:53Z",
"published": "2025-08-16T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38503"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0bcc14f36c7ad37121cf5c0ae18cdde5bfad9c4e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1961d20f6fa8903266ed9bd77c691924c22c8f02"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6bbe6530b1db7b4365ce9e86144c18c5d73b2c5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c77df23324f60bcff0ea44392e2c82e9486640c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4428b2d4c68732653e93f748f538bdee639ff80"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-PMG5-CQG9-W979
Vulnerability from github – Published: 2025-09-23 15:31 – Updated: 2025-09-23 15:31In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: fix panic on out-of-bounds guest IRQ
As guest_irq is coming from KVM_IRQFD API call, it may trigger crash in svm_update_pi_irte() due to out-of-bounds:
crash> bt PID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8" #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397 #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9 #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51 #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace [exception RIP: svm_update_pi_irte+227] RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086 RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001 RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8 RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200 R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001 R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm] #8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm] #9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm] RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020 RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0 R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0 R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b
Vmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() on out-of-bounds guest IRQ), so we can just copy source from that to fix this.
{
"affected": [],
"aliases": [
"CVE-2022-49154"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: fix panic on out-of-bounds guest IRQ\n\nAs guest_irq is coming from KVM_IRQFD API call, it may trigger\ncrash in svm_update_pi_irte() due to out-of-bounds:\n\ncrash\u003e bt\nPID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: \"vcpu8\"\n #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397\n #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d\n #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d\n #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d\n #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9\n #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51\n #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace\n [exception RIP: svm_update_pi_irte+227]\n RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086\n RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001\n RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8\n RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200\n R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001\n R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f\n ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n #7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm]\n #8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm]\n #9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm]\n RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246\n RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b\n RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020\n RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0\n R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0\n R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0\n ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b\n\nVmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() on\nout-of-bounds guest IRQ), so we can just copy source from that to fix\nthis.",
"id": "GHSA-pmg5-cqg9-w979",
"modified": "2025-09-23T15:31:07Z",
"published": "2025-09-23T15:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49154"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fb470eb48892e131d10aa3be6915239e65758f3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3fa2d747960521a646fc1aad7aea82e95e139a68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a6ffdebfb6a9c2ffeed902b544b96fe67498210e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a80ced6ea514000d34bf1239d47553de0d1ee89e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4d153d53d9648513481eb4ef8c212e7f1f8173d"
}
],
"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-PMJ8-XCC6-HFRP
Vulnerability from github – Published: 2025-11-05 15:31 – Updated: 2025-11-05 17:48A denial of service vulnerability exists in the g_assert_not_reached functionality of Entr'ouvert Lasso 2.5.1 and 2.8.2. A specially crafted SAML assertion response can lead to a denial of service. An attacker can send a malformed SAML response to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2025-46705"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-05T15:15:38Z",
"severity": "CRITICAL"
},
"details": "A denial of service vulnerability exists in the g_assert_not_reached functionality of Entr\u0026#39;ouvert Lasso 2.5.1 and 2.8.2. A specially crafted SAML assertion response can lead to a denial of service. An attacker can send a malformed SAML response to trigger this vulnerability.",
"id": "GHSA-pmj8-xcc6-hfrp",
"modified": "2025-11-05T17:48:28Z",
"published": "2025-11-05T15:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46705"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2025-2196"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2025-2196"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PMX2-4VWX-FC3H
Vulnerability from github – Published: 2024-03-26 18:32 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
These three bpf_map_{lookup,update,delete}_elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpf_jit_enable=0):
WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Call Trace: ? __warn+0xa5/0x240 ? bpf_map_lookup_elem+0x54/0x60 ? report_bug+0x1ba/0x1f0 ? handle_bug+0x40/0x80 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1b/0x20 ? __pfx_bpf_map_lookup_elem+0x10/0x10 ? rcu_lockdep_current_cpu_online+0x65/0xb0 ? rcu_is_watching+0x23/0x50 ? bpf_map_lookup_elem+0x54/0x60 ? __pfx_bpf_map_lookup_elem+0x10/0x10 bpfprog_run+0x513/0x3b70 bpf_prog_run32+0x9d/0xd0 ? __bpf_prog_enter_sleepable_recur+0xad/0x120 ? __bpf_prog_enter_sleepable_recur+0x3e/0x120 bpf_trampoline_6442580665+0x4d/0x1000 __x64_sys_getpgid+0x5/0x30 ? do_syscall_64+0x36/0xb0 entry_SYSCALL_64_after_hwframe+0x6e/0x76
{
"affected": [],
"aliases": [
"CVE-2023-52621"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-26T18:15:08Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check rcu_read_lock_trace_held() before calling bpf map helpers\n\nThese three bpf_map_{lookup,update,delete}_elem() helpers are also\navailable for sleepable bpf program, so add the corresponding lock\nassertion for sleepable bpf program, otherwise the following warning\nwill be reported when a sleepable bpf program manipulates bpf map under\ninterpreter mode (aka bpf_jit_enable=0):\n\n WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......\n CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......\n RIP: 0010:bpf_map_lookup_elem+0x54/0x60\n ......\n Call Trace:\n \u003cTASK\u003e\n ? __warn+0xa5/0x240\n ? bpf_map_lookup_elem+0x54/0x60\n ? report_bug+0x1ba/0x1f0\n ? handle_bug+0x40/0x80\n ? exc_invalid_op+0x18/0x50\n ? asm_exc_invalid_op+0x1b/0x20\n ? __pfx_bpf_map_lookup_elem+0x10/0x10\n ? rcu_lockdep_current_cpu_online+0x65/0xb0\n ? rcu_is_watching+0x23/0x50\n ? bpf_map_lookup_elem+0x54/0x60\n ? __pfx_bpf_map_lookup_elem+0x10/0x10\n ___bpf_prog_run+0x513/0x3b70\n __bpf_prog_run32+0x9d/0xd0\n ? __bpf_prog_enter_sleepable_recur+0xad/0x120\n ? __bpf_prog_enter_sleepable_recur+0x3e/0x120\n bpf_trampoline_6442580665+0x4d/0x1000\n __x64_sys_getpgid+0x5/0x30\n ? do_syscall_64+0x36/0xb0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n \u003c/TASK\u003e",
"id": "GHSA-pmx2-4vwx-fc3h",
"modified": "2025-11-03T21:31:01Z",
"published": "2024-03-26T18:32:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52621"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3516f93cc63d956e1b290ae4b7bf2586074535a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82f2df94dac1aa9b879e74d1f82ba1b631bdc612"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PPXC-FR36-G8V9
Vulnerability from github – Published: 2026-06-10 00:31 – Updated: 2026-06-10 00:31This issue can occur when running an aggregation pipeline that uses the internal $exchange stage configured with key-range partitioning and order-preserving delivery. If a single key range produces enough documents to fill its exchange buffer (that is, many results are routed to the same consumer), the server reaches the code path where a full per-consumer buffer is detected but the internal "high watermark" for that key range is not updated as intended.
{
"affected": [],
"aliases": [
"CVE-2026-9749"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T23:17:04Z",
"severity": "HIGH"
},
"details": "This issue can occur when running an aggregation pipeline that uses the internal $exchange stage configured with key-range partitioning and order-preserving delivery. If a single key range produces enough documents to fill its exchange buffer (that is, many results are routed to the same consumer), the server reaches the code path where a full per-consumer buffer is detected but the internal \"high watermark\" for that key range is not updated as intended.",
"id": "GHSA-ppxc-fr36-g8v9",
"modified": "2026-06-10T00:31:50Z",
"published": "2026-06-10T00:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9749"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/SERVER-124031"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-PQ6J-95Q4-4MHJ
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-03 18:30Processing of repeated responses to the same query, where both responses contain ECS pseudo-options, but where the first is broken in some way, can cause BIND to exit with an assertion failure. 'Broken' in this context is anything that would cause the resolver to reject the query response, such as a mismatch between query and answer name. This issue affects BIND 9 versions 9.11.4-S1 through 9.11.37-S1 and 9.16.8-S1 through 9.16.36-S1.
{
"affected": [],
"aliases": [
"CVE-2022-3488"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-26T21:15:00Z",
"severity": "HIGH"
},
"details": "Processing of repeated responses to the same query, where both responses contain ECS pseudo-options, but where the first is broken in some way, can cause BIND to exit with an assertion failure. \u0027Broken\u0027 in this context is anything that would cause the resolver to reject the query response, such as a mismatch between query and answer name. This issue affects BIND 9 versions 9.11.4-S1 through 9.11.37-S1 and 9.16.8-S1 through 9.16.36-S1.",
"id": "GHSA-pq6j-95q4-4mhj",
"modified": "2023-02-03T18:30:23Z",
"published": "2023-01-26T21:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3488"
},
{
"type": "WEB",
"url": "https://kb.isc.org/docs/cve-2022-3488"
}
],
"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-PQC9-XFP2-368X
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug_on in ext4_writepages
we got issue as follows: EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls ------------[ cut here ]------------ kernel BUG at fs/ext4/inode.c:2708! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90
It may happen as follows: 1. write inline_data inode vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> If inline data size too small will allocate block to write, then mapping will has dirty page ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA 2. fallocate do_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> fail will goto restore data ext4_restore_inline_data ext4_create_inline_data ext4_write_inline_data ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA 3. writepages __ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages if (ext4_has_inline_data(inode)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))
The root cause of this issue is we destory inline data until call ext4_writepages under delay allocation mode. But there maybe already convert from inline to extent. To solve this issue, we call filemap_flush first..
{
"affected": [],
"aliases": [
"CVE-2022-49347"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix bug_on in ext4_writepages\n\nwe got issue as follows:\nEXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls\n------------[ cut here ]------------\nkernel BUG at fs/ext4/inode.c:2708!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155\nRIP: 0010:ext4_writepages+0x1977/0x1c10\nRSP: 0018:ffff88811d3e7880 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000\nRDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002\nRBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000\nR10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001\nR13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028\nFS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n do_writepages+0x130/0x3a0\n filemap_fdatawrite_wbc+0x83/0xa0\n filemap_flush+0xab/0xe0\n ext4_alloc_da_blocks+0x51/0x120\n __ext4_ioctl+0x1534/0x3210\n __x64_sys_ioctl+0x12c/0x170\n do_syscall_64+0x3b/0x90\n\nIt may happen as follows:\n1. write inline_data inode\nvfs_write\n new_sync_write\n ext4_file_write_iter\n ext4_buffered_write_iter\n generic_perform_write\n ext4_da_write_begin\n ext4_da_write_inline_data_begin -\u003e If inline data size too\n small will allocate block to write, then mapping will has\n dirty page\n ext4_da_convert_inline_data_to_extent -\u003eclear EXT4_STATE_MAY_INLINE_DATA\n2. fallocate\ndo_vfs_ioctl\n ioctl_preallocate\n vfs_fallocate\n ext4_fallocate\n ext4_convert_inline_data\n ext4_convert_inline_data_nolock\n ext4_map_blocks -\u003e fail will goto restore data\n ext4_restore_inline_data\n ext4_create_inline_data\n ext4_write_inline_data\n ext4_set_inode_state -\u003e set inode EXT4_STATE_MAY_INLINE_DATA\n3. writepages\n__ext4_ioctl\n ext4_alloc_da_blocks\n filemap_flush\n filemap_fdatawrite_wbc\n do_writepages\n ext4_writepages\n if (ext4_has_inline_data(inode))\n BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))\n\nThe root cause of this issue is we destory inline data until call\next4_writepages under delay allocation mode. But there maybe already\nconvert from inline to extent. To solve this issue, we call\nfilemap_flush first..",
"id": "GHSA-pqc9-xfp2-368x",
"modified": "2025-09-22T21:30:16Z",
"published": "2025-09-22T21:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49347"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/013f12bdedb96816aaa27ee04349f4433d361f52"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18a759f7f99f0b65a08ff5b7e745fc405a42bde4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19918ec7717d87d5ab825884a46b26b21375d7ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b061af037646c9cdb0afd8a8d2f1e1c06285866"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1cde35417edc0370fb0179a4e38b78a15350a8d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73fd5b19285197078ee8a2e651d75d5b094a4de9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2b78f5bf2d453dda3903955efee059260787a42"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de1732b5c1693ad489c5d254f124f67cb775f37d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef09ed5d37b84d18562b30cf7253e57062d0db05"
}
],
"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-PQHC-9R4H-W7G3
Vulnerability from github – Published: 2023-12-05 03:30 – Updated: 2023-12-05 03:30Transient DOS in Modem when a Beam switch request is made with a non-configured BWP.
{
"affected": [],
"aliases": [
"CVE-2023-33043"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-05T03:15:11Z",
"severity": "HIGH"
},
"details": "Transient DOS in Modem when a Beam switch request is made with a non-configured BWP.",
"id": "GHSA-pqhc-9r4h-w7g3",
"modified": "2023-12-05T03:30:22Z",
"published": "2023-12-05T03:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33043"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/december-2023-bulletin"
}
],
"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-PQMQ-QJCG-MW2V
Vulnerability from github – Published: 2026-06-08 18:31 – Updated: 2026-07-08 21:30In the Linux kernel, the following vulnerability has been resolved:
net: txgbe: fix RTNL assertion warning when remove module
For the copper NIC with external PHY, the driver called phylink_connect_phy() during probe and phylink_disconnect_phy() during remove. It caused an RTNL assertion warning in phylink_disconnect_phy() upon module remove.
To fix this, add rtnl_lock() and rtnl_unlock() around the phylink_disconnect_phy() in remove function.
------------[ cut here ]------------ RTNL: assertion failed at drivers/net/phy/phylink.c (2351) WARNING: drivers/net/phy/phylink.c:2351 at phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464 Modules linked in: ... CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+ Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink] Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000 RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020 RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000 R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348 FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: txgbe_remove_phy+0xbb/0xd0 [txgbe] txgbe_remove+0x4c/0xb0 [txgbe] pci_device_remove+0x41/0xb0 device_remove+0x43/0x80 device_release_driver_internal+0x206/0x270 driver_detach+0x4a/0xa0 bus_remove_driver+0x83/0x120 driver_unregister+0x2f/0x60 pci_unregister_driver+0x40/0x90 txgbe_driver_exit+0x10/0x850 [txgbe] __do_sys_delete_module.isra.0+0x1c3/0x2f0 __x64_sys_delete_module+0x12/0x20 x64_sys_call+0x20c3/0x2390 do_syscall_64+0x11c/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x15a/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_fault+0x312/0x580 ? srso_alias_return_thunk+0x5/0xfbef5 ? __handle_mm_fault+0x9d5/0x1040 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events+0x101/0x1d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1e8/0x2f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x2f8/0x820 ? srso_alias_return_thunk+0x5/0xfbef5 ? irqentry_exit+0xb2/0x600 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
{
"affected": [],
"aliases": [
"CVE-2026-46287"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T17:16:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: txgbe: fix RTNL assertion warning when remove module\n\nFor the copper NIC with external PHY, the driver called\nphylink_connect_phy() during probe and phylink_disconnect_phy() during\nremove. It caused an RTNL assertion warning in phylink_disconnect_phy()\nupon module remove.\n\nTo fix this, add rtnl_lock() and rtnl_unlock() around the\nphylink_disconnect_phy() in remove function.\n\n ------------[ cut here ]------------\n RTNL: assertion failed at drivers/net/phy/phylink.c (2351)\n WARNING: drivers/net/phy/phylink.c:2351 at\nphylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464\n Modules linked in: ...\n CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+\n Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING\nPLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024\n RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink]\n Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7\n48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 \u003c67\u003e 48 0f b9 3a\ne9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90\n RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000\n RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020\n RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000\n R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348\n FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000)\nknlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0\n PKRU: 55555554\n Call Trace:\n \u003cTASK\u003e\n txgbe_remove_phy+0xbb/0xd0 [txgbe]\n txgbe_remove+0x4c/0xb0 [txgbe]\n pci_device_remove+0x41/0xb0\n device_remove+0x43/0x80\n device_release_driver_internal+0x206/0x270\n driver_detach+0x4a/0xa0\n bus_remove_driver+0x83/0x120\n driver_unregister+0x2f/0x60\n pci_unregister_driver+0x40/0x90\n txgbe_driver_exit+0x10/0x850 [txgbe]\n __do_sys_delete_module.isra.0+0x1c3/0x2f0\n __x64_sys_delete_module+0x12/0x20\n x64_sys_call+0x20c3/0x2390\n do_syscall_64+0x11c/0x1500\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? do_syscall_64+0x15a/0x1500\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? do_fault+0x312/0x580\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __handle_mm_fault+0x9d5/0x1040\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? count_memcg_events+0x101/0x1d0\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? handle_mm_fault+0x1e8/0x2f0\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? do_user_addr_fault+0x2f8/0x820\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? irqentry_exit+0xb2/0x600\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? exc_page_fault+0x92/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e",
"id": "GHSA-pqmq-qjcg-mw2v",
"modified": "2026-07-08T21:30:21Z",
"published": "2026-06-08T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46287"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0305e7118451c7c363c18f8113b0d8e0077ffa4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e223a7fd41ce6fffdb10577df9350385262bf33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c5ec52c68a6a442c8a159615ae092512562318a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d29cafc7e4ee9e28a150ba17e9a565ec5d881fbc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e159f05e12cc1111a3103b99375ddf0dfd0e7d63"
}
],
"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"
}
]
}
Mitigation
Make sensitive open/close operation non reachable by directly user-controlled data (e.g. open/close resources)
Mitigation
Strategy: Input Validation
Perform input validation on user data.
No CAPEC attack patterns related to this CWE.