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]
Date: Tue, 23 Jan 2024 09:57:33 +1030
From: Qu Wenruo <quwenruo.btrfs@....com>
To: dsterba@...e.cz, Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Sterba <dsterba@...e.com>, Qu Wenruo <wqu@...e.com>,
 linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Btrfs fixes for 6.8-rc2



On 2024/1/23 09:35, David Sterba wrote:
> On Mon, Jan 22, 2024 at 02:54:31PM -0800, Linus Torvalds wrote:
>> On Mon, 22 Jan 2024 at 14:34, Linus Torvalds
>> <torvalds@...ux-foundation.org> wrote:
>>>
>>> Bah. These fixes are garbage. Now my machine doesn't even boot. I'm
>>> bisecting
>
> Ah, sorry.
>
>> My bisection says
>>
>>     1e7f6def8b2370ecefb54b3c8f390ff894b0c51b is the first bad commit
>
> We got a report today [1] that this commit is indeed bad,
>
> https://lore.kernel.org/linux-btrfs/CABq1_vj4GpUeZpVG49OHCo-3sdbe2-2ROcu_xDvUG-6-5zPRXg@mail.gmail.com/
>
> the timing was also unfortuate and too late to recall the pull request.

All my fault.

The offending line is:

+	memcpy_to_page(dest_page, dest_pgoff + to_copy, workspace->out_buf.dst,
+		       to_copy);

I'm using the bad pg_off for the memcpy_to_page() call.
And zstd is the only affected algo.

All the other algos go like this:

+	memcpy_to_page(dest_page, dest_pgoff, workspace->buf, out_len);

So that's why it's screwing up the zstd compressed inline extent
decompression, as we can easily write beyond the page boundary and write
into the next innocent page.

And the existing compression group didn't catch it at all.

Would fix it and add new test cases for the regression.

Thanks,
Qu
>
>> but I'll still have to verify by testing the revert on top of my current tree.
>>
>> It did revert cleanly, but I also note that if the zstd case is wrong,
>> I assume the other very similar commits (for zlib and lzo) are
>> potentially also wrong.
>>
>> Let me reboot to verify that at least my machine boots.
>
> Per the report revert makes it work again and zlib and lzo cases are not
> affected.
>
> I can send a pull request reverting all the three until we figure out
> what's wrong, or you can do it as all revert cleanly.
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ