linux-kernel - Re: [PATCH 1/1] btrfs: add integer overflow protection to flush_dir_items_batch allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250730072006.154135-1-admin@mail.free-proletariat.dpdns.org>
Date: Wed, 30 Jul 2025 16:20:06 +0900
From: kmpfqgdwxucqz9@...il.com
To: Qu Wenruo <quwenruo.btrfs@....com>
Cc: Johannes Thumshirn <Johannes.Thumshirn@....com>,
	David Sterba <dsterba@...e.com>,
	linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	KernelKraze <admin@...l.free-proletariat.dpdns.org>
Subject: Re: [PATCH 1/1] btrfs: add integer overflow protection to flush_dir_items_batch allocation - WITHDRAWN

From: KernelKraze <admin@...l.free-proletariat.dpdns.org>

Hi Qu,

Thank you for the detailed technical review and correction. You are absolutely right, and I'm withdrawing this patch.

On 7/30/25 4:36 PM, Qu Wenruo wrote:
> Just as Johannes said, explain this number.
> And the magic number 195 won't cause any overflow anyway.
> [...]
> Finally, have you checked the only caller of flush_dir_items_batch()?

You've identified several fundamental issues with my patch:

1. **Misunderstanding of the caller context**: I failed to properly analyze that process_dir_items_leaf() iterates through leaf node items, where batch_size naturally corresponds to the number of directory entries in a leaf.

2. **Inappropriate limit**: The 195 limit would indeed cause false alerts on valid large directories, especially with 16K nodesize supporting 200+ directory items as you correctly calculated.

3. **Unnecessary complexity**: The integer overflow protection is not needed in this context where the count is bounded by filesystem structure limits, not user input.

4. **Architecture insensitivity**: I didn't consider systems with different page sizes where the 4K limit makes no sense.

I clearly should have done more thorough analysis of the btrfs architecture and actual usage patterns before proposing this change. Your feedback is invaluable for understanding how directory logging actually works in btrfs.

**This patch is hereby WITHDRAWN.**

Thank you for taking the time to provide such detailed technical education. I'll study the btrfs codebase more thoroughly before future contributions.

Best regards,
KernelKraze