linux-kernel - Re: [Bug] Memory allocation errors and system crashing due to buggy disk cache/inode allocations by ntfs3 kernel module.

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] [day] [month] [year] [list]

Message-ID: <ee9a1718-7feb-4ff4-8b1e-582b8aca85b4@paragon-software.com>
Date: Fri, 14 Nov 2025 10:39:46 +0100
From: Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
To: <craftfever@...amail.com>, Thorsten Leemhuis <regressions@...mhuis.info>
CC: Ntfs3 <ntfs3@...ts.linux.dev>, Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Bug] Memory allocation errors and system crashing due to buggy
 disk cache/inode allocations by ntfs3 kernel module.

On 10/4/25 13:26, craftfever@...amail.com wrote:

> I'm posting there first time, so I through it like generic bug mailing list, but I can say, that, for example, version 6.12.50-lts a little less pron to bug, but it occurs there as well. I'm using Linux 6.16.10 for now. So, bug is present a while, but i hardly to tell, in what kernel version it appeared, cause earlier, I didn't manage that big amount of files. Again, it's okay with ntfs-3g.
>
> Oct 4, 2025, 14:12 by regressions@...mhuis.info:
>
>>
>> On 10/4/25 13:03, craftfever@...amail.com wrote:
>>
>>> Oct 4, 2025, 11:55 by craftfever@...amail.com:
>>>
>>>> I'm expecting serious bug when writing large amount of files to
>>>> NTFS hard drive, shortly after memory allocation errors and system
>>>> crash occurs/ Firstly, I thought, than this is bug in linux kernel
>>>> itself, somewhat disk cache allocation error, but when I tested
>>>> same operations on ext4 drive or using NTFS-3G module, bug is not
>>>> present.
>>>>
>>> To reproduce a bug, try cloning two big Git repositories to an
>>> external NTFS drive mounted with ntfs3 module.
>>>
>> Thx for the report.
>>
>> What kernel version are your using?
>>
>> You CCed the regression list, so I assume this used to work, which leads
>> to two more questions: What was the last version where this works? Could
>> you bisect?
>>
>> Ciao, Thorsten
>>
Hello,

I tried to reproduce the problem by cloning multiple large Git repositories
onto an ntfs3-mounted NTFS volume, but the issue did not trigger on my side
and no system crash occurred.

Could you provide a bit more detail about your case?

- What appears in the kernel logs before the crash or before the process
   enters the unkillable state? Any warnings, memory allocation errors,
   stack traces, or lockdep messages from dmesg would be very useful.
- What mount options are you using for ntfs3?
- Roughly how much data or how many files are needed to trigger the
   behavior?
- Does the problem happen immediately, or only after sustained I/O or high
   memory pressure?

If you can capture the relevant portion of dmesg or the last messages
shown before the freeze/hang, that would help a lot in diagnosing this.

Regards,
Konstantin