NAK: [X] [PATCH] fixes for LP: #1415636/CVE-2015-1350

Kleber Souza kleber.souza at
Thu Aug 2 12:25:26 UTC 2018

On 08/02/18 11:03, José Pekkarinen wrote:
> On Thursday, 2 August 2018 11:01:34 EEST Kleber Souza wrote:
>> On 08/01/18 16:58, José Pekkarinen wrote:
>>> fs: Avoid premature clearing of capabilities(030b533c4fd)
>>> Reviewed-by: Christoph Hellwig <hch at>
>>> by: Jan Kara <jack at>
>>> It's applied on:
>>> UBUNTU: Ubuntu-lts-3.19.0-82.90~14.04.1(ceea1114793f68).
>>> Signed-off-by: Brad Figg <brad.figg at>
>> Hi José,
>> We don't have any 3.19 based kernel that's currently supported, was the
>> patch really backported for the version stated above?
> 	Yes it's, I didn't find any other 3.x kernel for xenial, 4.x is supposed 
> not to be affected according to the information on the CVE. Is there any 
> source I'm missing on the run?

That version you mentioned above seems to be a Vivid backport for
Trusty, we never had a 3.x kernel version for Xenial. We only do
backports and not forward ports of kernels.

According to the CVE page [1], the linux package is still affected on
Xenial (4.4) and on Trusty (3.13). So the linux trees that need to be
used for the backport are xenial/master-next [2] and trusty/master-next
[3] branches.





>>> Currently, notify_change() clears capabilities or IMA attributes by
>>> calling security_inode_killpriv() before calling into ->setattr. Thus it
>>> happens before any other permission checks in inode_change_ok() and user
>>> is thus allowed to trigger clearing of capabilities or IMA attributes
>>> for any file he can look up e.g. by calling chown for that file. This is
>>> unexpected and can lead to user DoSing a system.
>>> Fix the problem by calling security_inode_killpriv() at the end of
>>> inode_change_ok() instead of from notify_change(). At that moment we are
>>> sure user has permissions to do the requested change.
>>> References: CVE-2015-1350
>>> Signed-off-by: José Pekkarinen <jose.pekkarinen at>
>> The body of the email doesn't follow our patch format for kernel SRU
>> requests. Please re-submit the patch following the format as described at:
> 	I'll fix that for the following. Thanks!
> 	José.

More information about the kernel-team mailing list