linux-kernel - Re: [GIT PULL] Btrfs changes for 4.15

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]

Date:   Wed, 15 Nov 2017 19:59:31 +0000 (UTC)
From:   Duncan <1i5t5.duncan@....net>
To:     linux-kernel@...r.kernel.org
Cc:     linux-btrfs@...r.kernel.org
Subject: Re: [GIT PULL] Btrfs changes for 4.15

Qu Wenruo posted on Tue, 14 Nov 2017 07:39:11 +0800 as excerpted:

>> New features:
>> 
>> - extend mount options to specify zlib compression level, -o
>> compress=zlib:9
> 
> However the support for it has a big problem, it will cause wild memory
> access for "-o compress" mount option.
> 
> Kernel ASAN can detect it easily and we already have user report about
> it. Btrfs/026 could also easily trigger it.
> 
> The fixing patch is submitted some days ago:
> https://patchwork.kernel.org/patch/10042553/
> 
> And the default compression level when not specified is zero, which
> means no compression but directly memory copy.

When not specified means ???

There's a couple possibilities:

* -o compress (zlib as default, no compression level specified)

* -o compress=zlib (zlib specified, no compression level specified)

Maybe both are considered unspecified and thus no compression, now?

Regardless, defaulting to zero compression changes current behavior, 
doesn't it?  It's also entirely unintuitive that specifying compression 
means _no_ compression.

With both that and the wild memory access being known issues, why is this 
being merged without the known fix (at least to the wild memory access) 
folded in, potentially breaking bisects even if people are more careful 
than to start testing pre-rc1.

-o compress=lzo continues to work as expected, I hope?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman