linux-kernel - RE: [PATCH] stm class: Fix out of bound access from bitmap allocation

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]

Message-ID: <fcc635f7984a4fe786e37f4c04a6cd86@AcuMS.aculab.com>
Date:   Mon, 8 Apr 2019 11:13:33 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Robin Murphy' <robin.murphy@....com>,
        Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mulu He <muluhe@...eaurora.org>,
        Tingwei Zhang <tingwei@...eaurora.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        "Mike Leach" <mike.leach@...aro.org>, Leo Yan <leo.yan@...aro.org>
CC:     Rajendra Nayak <rnayak@...eaurora.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Sibi Sankar <sibis@...eaurora.org>,
        Vivek Gautam <vivek.gautam@...eaurora.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH] stm class: Fix out of bound access from bitmap allocation

From: Robin Murphy
> Sent: 08 April 2019 11:52
> On 08/04/2019 11:33, David Laight wrote:
> > From: Robin Murphy
> >> Sent: 08 April 2019 11:24
> >> On 07/04/2019 05:31, Sai Prakash Ranjan wrote:
> >>> On 4/5/2019 6:44 PM, David Laight wrote:
> >>>> From: Sai Prakash Ranjan
> >>>>>
> >>>>> diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
> >>>>> index 93ce3aa740a9..21a5838f6e67 100644
> >>>>> --- a/drivers/hwtracing/stm/core.c
> >>>>> +++ b/drivers/hwtracing/stm/core.c
> >>>>> @@ -168,7 +168,7 @@ static int stp_master_alloc(struct stm_device
> >>>>> *stm, unsigned int idx)
> >>>>>        struct stp_master *master;
> >>>>>        size_t size;
> >>>>>
> >>>>> -    size = ALIGN(stm->data->sw_nchannels, 8) / 8;
> >>>>> +    size = ALIGN(stm->data->sw_nchannels, STM_MASTER_SZ) /
> >>>>> STM_MASTER_SZ;
> >>>>
> >>>> I'm not sure that using STP_MASTER_SZ improves readability at all.
> >>>>
> >>>
> >>> I thought it was better to have a macro than directly specifying
> >>> sizeof(unsigned long), anyways I can change it.
> >>>
> >>>> Is there something that gives the size of a bitmap for 'n' items?
> >>>>
> >>>
> >>> Not sure if there is something.
> >>
> >> If you were to ask the question "how does the bitmap code itself know
> >> what the total size of a bitmap is?", that would quickly lead you
> >> towards BITS_TO_LONGS() ;)
> >>
> >> And given that stp_master::chan_map is already an appropriate type, that
> >> suggests simplifying the entire calculation down to something neat and
> >> tidy like:
> >>
> >> size = offsetof(struct stp_master, chan_map[BITS_TO_LONGS(stm->data->sw_nchannels)]);
> >
> > Except that is invalid.
> > You can't use offsetof() with something that isn't a compile time constant.
> 
> Oh, I see the standard does actually say that, although there seem to be
> enough non-constant uses in the kernel to suggest that it still works in
> practice.

One of the compilers we use here complains about it - won't be a linux one.
It also fails to generate compile time constants (for static initialisers)
if you multiply or divide the result of anything that looks like offsetof()
applied to an array element (which is a bug).

I'd guess that the requirement in the standard was added because some
compilers were generating a result that wasn't a compile-time constant
and no one thought you'd want to pass a non-constant argument.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)