linux-kernel - Re: [PATCH 3.13 163/163] lzo: check for length overrun in variable length encoding.

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:	Thu, 16 Oct 2014 12:50:54 +0200
From:	Luis Henriques <luis.henriques@...onical.com>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kamal Mostafa <kamal@...onical.com>,
	kernel-team@...ts.ubuntu.com, Willy Tarreau <w@....eu>,
	stable@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3.13 163/163] lzo: check for length overrun in variable
 length encoding.

On Thu, Oct 16, 2014 at 10:10:30AM +0200, Jiri Slaby wrote:
> On 10/14/2014, 10:58 AM, Luis Henriques wrote:
> > Could you please provide us with examples of commits in one of our
> > extended stable trees that is not on any other public release at
> > kernel.org?
> 
> Hi, from 3.12.y, for example:
> commit 48e8cad86bb1241c08bdaa80db022c25068ff8e0
> Author: Jiri Slaby <jslaby@...e.cz>
> Date:   Mon Jul 14 15:20:17 2014 +0200
> 
>     Revert "aio: fix kernel memory disclosure in io_getevents()
> introduced in v3.10"
> 
>     This reverts commit 0e2e24e5dc6eb6f0698e9dc97e652f132b885624, which
>     was applied twice mistakenly. The first one is
>     bee3f7b8188d4b2a5dfaeb2eb4a68d99f67daecf.
> 
> 
> Or any other patch without the "commit upstream" line. This may also
> happen where there is no way of backporting a fix to the stable tree due
> to later changes. Instead, a simple fix is applied, but it has no
> connection to the original commit but the reference.
> 

Thank you for your reply Jiri, but I believe you're referring to
commits that are in stable kernels and that are not on Linus tree.  I
do understand that these are required occasionally for the reasons you
stated above, and they are usually provided by subsystem maintainers.

However, the initial discussion was about commits that are not in a
public release (e.g. a Linus rc kernel) at kernel.org.

Cheers,
--
Luís
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/