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:	Sun, 14 Aug 2016 21:02:48 +0200
From:	Vegard Nossum <vegard.nossum@...cle.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	"Theodore Ts'o" <tytso@....edu>, adilger.kernel@...ger.ca,
	linux-ext4@...r.kernel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: ext4: fix reference counting bug on block allocation error

On 08/14/2016 08:58 PM, Greg KH wrote:
> On Sun, Aug 14, 2016 at 08:51:25PM +0200, Greg KH wrote:
>> On Sun, Aug 14, 2016 at 08:37:56PM +0200, Vegard Nossum wrote:
>>> On 08/14/2016 08:32 PM, Greg KH wrote:
>>>> Hi Vegard and ext4 developers,
>>>>
>>>> The patch below, in Linus's tree, references a patch in the Fixes: line
>>>> that is not in Linus's tree (neither the git commit id, nor the subject
>>>> line.)
>>>>
>>>
>>> It seems to exist?
>>>
>>>>> Fixes: 8556e8f3b6 ("ext4: Don't allow new groups to be added during block
>>> allocation")
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8556e8f3b6c4c11601ce1e9ea8090a6d8bd5daae
>>>
>>>> That's a bit confusing, what is this patch supposed to be fixing up?
>>>> What stable tree(s) should it go to if the original patch it fixes isn't
>>>> even in any tree?
>>>
>>> The referenced commit adds the ext4_mb_release_context(ac); line which
>>> is what is causing problems because that releases the context which is
>>> still in fact in use.
>>
>> Oh doh, sorry for the noise, I was only looking at 4.8-rc1 and older, my
>> fault.
>
> Hm, wait.  Commit 8556e8f3b6 didn't show up in my filters for some
> reason (which it not good, and makes me worry), but also, it doesn't
> apply to the stable trees at all.
>
> So can you please send backports of that commit, and this one, if you
> want them both queued up to any stable kernel tree?

The commit which is being fixed is ancient:

$ git describe 8556e8f3b6
v2.6.28-5758-g8556e8f3

It's probably already in the base of every current stable tree, no?


Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ