Evidence used
- No CISA KEV confirmation is currently recorded.
- EPSS is 0.22% for the current model date.
BlackTreeCVE IntelligenceFull vulnerability report · 2026
CVE-2026-74351High confidence
ocfs2: rebase copied fsdlm LVB pointers in locking_state
Linux · Linux
…UnscoredAssess manually
Patch only the product branches with a verified fix
Fix availability varies by productNo CVSS base score is available from the CNA, CISA ADP or NIST. Absence of a score is not evidence of low risk; review the vendor advisory, affected exposure and exploit evidence. Verified remediation exists for at least one product or source, but 20 structured product or package states remain unresolved. Apply remediation only to the exact product branch confirmed by its source.
R
Open reassessment dashboard →Operational reassessment
Published severity in operational context
Published severityUnscored→Operational priority:Needs assessment, manual assessment needed.unscored
Compensating controls
- Validate the affected product branch and deploy the verified fixed release.
- Restrict local access and enforce least privilege on affected hosts.
- Monitor vendor guidance and exploitation sources for a material change.
Verification
- Confirm that the asset runs Linux Linux and falls inside the recorded affected range.
- Verify the installed build against the product-specific fixed version after deployment.
- Validate exposure, authentication requirements and compensating controls in the actual environment.
- Reopen this reassessment when CVSS, KEV, EPSS, exploit evidence or remediation changes.
Remediation availability differs by product scope
Verified remediation exists for at least one product or source, but 20 structured product or package states remain unresolved. Apply remediation only to the exact product branch confirmed by its source.
- Canonical Ubuntu Security: 20 affected package states with no published fix
Distribution package intelligence
24 package statesRelease-specific package status
Debian, ubuntu findings are scoped to the named distribution, release and source package. An absent finding does not mean a package is unaffected.
Package result overrides the generic status
BlackTree has verified remediation for at least one product or source, but the relevant distribution still reports no fixed package for 20 affected package states shown here. Treat those rows as affected with no fix until that distribution publishes a fixed version.
Repository candidate not checked
A published vendor fix does not prove that a matching update is enabled and installable on a particular asset. Confirm the local package candidate before scheduling remediation.
| Distribution release | Source package | Vendor state | Fixed version | Evidence |
|---|---|---|---|---|
| Debian trixietrixie · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 6.12.100-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian bookwormbookworm · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 6.1.180-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian forkyforky · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 7.1.5-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian sidsid · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 7.1.5-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-aws | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-azure | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-azure-fde | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-azure-nvidia | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-gcp | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-gke | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-gkeop | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-ibm | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-lowlatency | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-nvidia | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-nvidia-lowlatency | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-nvidia-tegra | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-oem-6.11 | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-oracle | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-raspi | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-raspi-realtime | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-realtime | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-riscv | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-xilinx | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
Direct vendor intelligence
1 currentAuthoritative vendor CSAF and VEX advisories
Structured product status and remediation from the issuing vendor. Product-state explanations are always visible; large lists can be searched or downloaded.
CVE-2026-74351 · CSAF 2.0 · revision 3 · finalRed Hat Product Securitykernel: ocfs2: rebase copied fsdlm LVB pointers in locking_state
The vendor explicitly states that these products are not affected by this CVE.
- kernel as a component of Red Hat Enterprise Linux 10
- kernel-64k as a component of Red Hat Enterprise Linux 10
- kernel-64k-core as a component of Red Hat Enterprise Linux 10
- kernel-64k-debug as a component of Red Hat Enterprise Linux 10
- kernel-64k-debug-core as a component of Red Hat Enterprise Linux 10
- kernel-64k-debug-devel as a component of Red Hat Enterprise Linux 10
- kernel-64k-debug-devel-matched as a component of Red Hat Enterprise Linux 10
- kernel-64k-debug-modules as a component of Red Hat Enterprise Linux 10
- kernel-64k-debug-modules-core as a component of Red Hat Enterprise Linux 10
- kernel-64k-debug-modules-extra as a component of Red Hat Enterprise Linux 10
- kernel-64k-devel as a component of Red Hat Enterprise Linux 10
- kernel-64k-devel-matched as a component of Red Hat Enterprise Linux 10
- Summary
- A flaw was found in the `ocfs2` component of the Linux kernel. The `locking_state` debugfs iterator incorrectly handles pointers to lock resource blocks (LVB). When the original lock resource is freed while the iterator still holds a pointer to it, a use-after-free vulnerability occurs. This can lead to a system crash, resulting in a Denial of Service (DoS).
- Remediation
- No remediation text is recorded.
No CVSS base score is available from the CNA, CISA ADP or NIST. Absence of a score is not evidence of low risk; review the vendor advisory, affected exposure and exploit evidence. Verified remediation exists for at least one product or source, but 20 structured product or package states remain unresolved. Apply remediation only to the exact product branch confirmed by its source.
Fix availability varies by product01
What, why and how
In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f
What
In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f
Why
The current structured CVE record identifies a security weakness, but the root cause requires confirmation in the linked vendor material.
How
An attacker operating through the affected interface may attempt exploitation when the stated preconditions are met. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
What
In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f
Why
The current structured CVE record identifies a security weakness, but the root cause requires confirmation in the linked vendor material.
How
An attacker operating through the affected interface may attempt exploitation when the stated preconditions are met. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
02
Exploit reality and attack path
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
Observed exploitation No confirmed evidence
?
Confirmed exploitation and public exploit material are separate signals. Attacks can occur without public proof-of-concept or exploit code.No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
Public PoC / exploit material None recorded
?
Confirmed exploitation and public exploit material are separate signals. Attacks can occur without public proof-of-concept or exploit code.No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
- Likely attack path
- the affected interface → vulnerable operation → cause the confidentiality, integrity or availability impact described by the vendor
- Attack surface
- Unspecified
- Privileges required
- Not stated in the selected CVSS metric
- User interaction
- Not stated in the selected CVSS metric
- Attack complexity
- Not stated in the selected CVSS metric
- Security boundary
- Not stated in the selected CVSS metric
- Weakness
?
CWE means Common Weakness Enumeration. - CWE not yet assigned
- CVSS vector
?
CVSS means Common Vulnerability Scoring System. The vector records the metric values used to calculate technical severity. Not available from the selected scoring authority.- Post-exploitation / living off the land
- No specific living-off-the-land technique is confirmed in the structured sources. Monitor normal administration tools for activity inconsistent with the affected service's baseline.
03
Patch and workaround
Operational remediation based on structured source evidence.
- Status
?
Patch availability is based on structured fixed-version fields and authoritative update references. If no fix is verified, check the vendor advisory before making a change. - Fix availability varies by product
- Action
- Use the product-specific evidence above. Patch only products with a verified fixed release, and keep every affected or under-investigation state without a matching fix in the remediation queue.
- Workaround
- No verified workaround is recorded. Limit untrusted access and use least privilege until authoritative guidance is available.
04
Evidence and provenance
Published 15 Aug 2026 · Last source change 17 Aug 2026, 05:17 UTC · CWE not yet assigned
CVE recordCVE.org · 5.2
CVSS sourceUnavailable
EPSS source FIRST · tracked since 2026-08-23
?
The date BlackTree first stored a score for this CVE from the daily FIRST EPSS feed.European sourceENISA EUVD · EUVD-2026-59498
Product sourceCNA
Remediation sourceCVE/CNA references
CWE sourceUnavailable
NVD statusNVD received
Missing structured fields: CVSS base score, CWE classification. Missing data is not evidence of low risk; review the primary advisory.
Material change intelligence
View recent updates ↗What changed after publication
- Catalogue recordCVE added to the BlackTree catalogue.CNA ↗
- Vendor guidanceAuthoritative vendor guidance changed: added remediation: git.kernel.org/185427b5f7a209254c85c18aad5a4a8e009b2f30; removed remediation: git.kernel.org/07aa4a8ebacde3d0ba50f60d2964f274ee7629bc.CNA ↗
- Before
- remediation: git.kernel.org/07aa4a8ebacde3d0ba50f60d2964f274ee7629bc
- After
- remediation: git.kernel.org/185427b5f7a209254c85c18aad5a4a8e009b2f30
CVE published
Fixed release or patch reference recorded
Technical terms and abbreviations used in this report
- CVE
- Common Vulnerabilities and Exposures: the public identifier for one disclosed vulnerability.
- CVSS
- Common Vulnerability Scoring System: a technical severity framework; it is not patching priority by itself.
- EPSS
- Exploit Prediction Scoring System: FIRST's estimate of the probability that exploitation activity will be observed in the next 30 days; it is a forecast, not confirmation.
- CWE
- Common Weakness Enumeration: the standard category describing the underlying software or hardware weakness.
- CNA
- CVE Numbering Authority: an organisation authorised to assign and publish CVE records.
- CISA ADP
- Cybersecurity and Infrastructure Security Agency Authorized Data Publisher: structured enrichment added to a CVE record.
- NVD
- National Vulnerability Database: NIST's enrichment service for CVE records.
- CERT / CSIRT
- A computer security incident response team that publishes warnings or coordinates incident response.
- PoC
- Proof of concept: public material that demonstrates or helps reproduce exploitation.
- CSAF
- Common Security Advisory Framework: a machine-readable format for security advisories.
- LoTL
- Living off the land: abuse of legitimate tools or system functions during an attack.