linux-kernel - Re: [PATCH] zram: set physical queue limits to avoid array out of bounds accesses

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:   Fri, 31 Mar 2017 08:45:54 +0900
From:   Minchan Kim <minchan@...nel.org>
To:     Jens Axboe <axboe@...com>
CC:     Johannes Thumshirn <jthumshirn@...e.de>,
        Hannes Reinecke <hare@...e.de>,
        Nitin Gupta <ngupta@...are.org>,
        Christoph Hellwig <hch@....de>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        <yizhan@...hat.com>,
        Linux Block Layer Mailinglist <linux-block@...r.kernel.org>,
        Linux Kernel Mailinglist <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] zram: set physical queue limits to avoid array out of
 bounds accesses

On Thu, Mar 30, 2017 at 09:35:56AM -0600, Jens Axboe wrote:
> On 03/30/2017 09:08 AM, Minchan Kim wrote:
> > Hi Jens,
> > 
> > It seems you miss this.
> > Could you handle this?
> 
> I can, but I'm a little confused. The comment talks about replacing
> the one I merged with this one, I can't do that. I'm assuming you
> are talking about this commit:

Right.

> 
> commit 0bc315381fe9ed9fb91db8b0e82171b645ac008f
> Author: Johannes Thumshirn <jthumshirn@...e.de>
> Date:   Mon Mar 6 11:23:35 2017 +0100
> 
>     zram: set physical queue limits to avoid array out of bounds accesses
> 
> which is in mainline. The patch still applies, though.

You mean it's already in mainline so you cannot replace but can revert.
Right?
If so, please revert it and merge this one.

> 
> Do we really REALLY need this for 4.11, or can we queue for 4.12 and
> mark it stable?

Not urgent because one in mainline fixes the problem so I'm okay
with 4.12 but I don't want mark it as -stable.

Thanks!