btrfs: clean up our handling of refs == 0 in snapshot delete
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
2.6.31
References 8
git.kernel.org
- stable/c/c847b28a799733b04574060ab9d00f215970627d
- stable/c/71291aa7246645ef622621934d2067400380645e
- stable/c/c60676b81fab456b672796830f6d8057058f029c
- stable/c/728d4d045b628e006b48a448f3326a7194c88d32
- stable/c/9cc887ac24b7a0598f4042ae9af6b9a33072f75b
- stable/c/7d1df13bf078ffebfedd361d714ff6cee1ff01b9
- stable/c/03804641ec2d0da4fa088ad21c88e703d151ce16
- stable/c/b8ccef048354074a548f108e51d0557d6adfd3a3