Threats Tagged 'ghsa-6p99-w6f4-qcvq'
View all threats tagged with 'ghsa-6p99-w6f4-qcvq'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'ghsa-6p99-w6f4-qcvq'
Click on any threat for detailed analysis and mitigation recommendations
In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK… (CVE-2026-64600)CVE-2026-64600 0 In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle. Join the discussion | GCVE Database | 07/23/2026, 06:32:13 UTC Added: 07/28/2026, 23:52:09 UTC |
Showing 1 to 1 of 1 result