From: bugzilla-daemon@kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 220342] New: After file delete, extent index structure remains unchanged
Date: Tue, 15 Jul 2025 13:29:25 +0000 [thread overview]
Message-ID: <bug-220342-13602@https.bugzilla.kernel.org/> (raw)
https://bugzilla.kernel.org/show_bug.cgi?id=220342
Bug ID: 220342
Summary: After file delete, extent index structure remains
unchanged
Product: File System
Version: 2.5
Kernel Version: 6.16-rc6
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: ext4
Assignee: fs_ext4@kernel-bugs.osdl.org
Reporter: bretznic@gmail.com
Regression: No
Created attachment 308380
--> https://bugzilla.kernel.org/attachment.cgi?id=308380&action=edit
ext
When a file without extents is deleted, eh_entries and eh_depth are cleared, as
well as ee_start_hi and ee_start_lo.
When a file with extents is deleted, eh_entries and eh_depth are also cleared,
but ei_leaf_hi and ei_leaf_lo are not cleared in the top inode.
The attached screenshots of hexdumps show the issue before vs. after deletion,
for non-extent and extent files.
With ei_leaf_hi and ei_leaf_lo still present, it's easy to reach the data
blocks.
Having said this, extent files have (regular) extent structures lower in the
tree, and those are not cleared. (Unlike the regular extent structures of
non-extent files)
I don't know if it's worth clearing those structures as well. I guess for most
instances it's not, and for security conscious users it would probably be a
nice to have. But then, where to stop? I don't know...
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next reply other threads:[~2025-07-15 13:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 13:29 bugzilla-daemon [this message]
2025-07-15 13:29 ` [Bug 220342] After file delete, extent index structure remains unchanged bugzilla-daemon
2025-07-15 13:41 ` bugzilla-daemon
2025-07-18 12:30 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-220342-13602@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox