linux-kernel - Re: linux-next: manual merge of the staging tree with the staging.current tree

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:   Tue, 9 Apr 2019 18:39:42 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Jonathan Cameron <jonathan.cameron@...wei.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>, Greg KH <greg@...ah.com>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        linux-iio@...r.kernel.org,
        Alexandru Ardelean <alexandru.ardelean@...log.com>
Subject: Re: linux-next: manual merge of the staging tree with the
 staging.current tree

On Mon, Apr 08, 2019 at 01:01:51PM +0100, Jonathan Cameron wrote:
> On Mon, 8 Apr 2019 13:34:37 +0300
> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
> > On Mon, Apr 08, 2019 at 11:14:39AM +0100, Jonathan Cameron wrote:
> > > On Mon, 8 Apr 2019 13:01:21 +0300
> > > Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:  
> > > > On Mon, Apr 08, 2019 at 09:14:58AM +0100, Jonathan Cameron wrote:  
> > > > > On Mon, 8 Apr 2019 13:02:12 +1000
> > > > > Stephen Rothwell <sfr@...b.auug.org.au> wrote:  

> > > > > That is the correct resolution.    
> > > > 
> > > > I think it still misses the following fix:  
> > 
> > > Is that actually a problem given it's copied over from buffer->scan_mask just after allocation?
> > > The two masks are the same length so I don't think we have a problem with this one.
> > > Am I missing something?  
> > 
> > Hmm... I didn't get why the commit 20ea39ef9f2f fixes anything.
> > 
> Good point.  I'm don't think it ever did.  
> 
> Alex, any thoughts?

I have a thought that it might be possible that somewhere code is still broken,
i.e. accessing bitmap behind the size (for example, iterating by unsigned long
without bitmap size being aligned to size of unsigned long).

If this is a case, the mentioned patch has a symptomatic healing and not fixing
a root cause.

-- 
With Best Regards,
Andy Shevchenko