linux-kernel - Re: [PATCH v3 3/4] drm/mediatek: Add casting before assign

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] [day] [month] [year] [list]

Date:   Tue, 18 Jul 2023 15:30:43 +0000
From:   Jason-JH Lin (林睿祥) 
        <Jason-JH.Lin@...iatek.com>
To:     CK Hu (胡俊光) <ck.hu@...iatek.com>,
        "amergnat@...libre.com" <amergnat@...libre.com>,
        "chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
        "David.Laight@...LAB.COM" <David.Laight@...LAB.COM>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        Singo Chang (張興國) 
        <Singo.Chang@...iatek.com>,
        Johnson Wang (王聖鑫) 
        <Johnson.Wang@...iatek.com>,
        Jason-ch Chen (陳建豪) 
        <Jason-ch.Chen@...iatek.com>,
        Shawn Sung (宋孝謙) 
        <Shawn.Sung@...iatek.com>,
        Nancy Lin (林欣螢) <Nancy.Lin@...iatek.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        Project_Global_Chrome_Upstream_Group 
        <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>
Subject: Re: [PATCH v3 3/4] drm/mediatek: Add casting before assign

Hi David,

Thanks for the reviews.

On Mon, 2023-07-17 at 13:17 +0000, David Laight wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  From: Jason-JH Lin
> > Sent: 14 July 2023 07:46
> > 
> > Hi CK,
> > 
> > Thanks for the reviews.
> > 
> > On Fri, 2023-07-14 at 05:45 +0000, CK Hu (胡俊光) wrote:
> > > Hi, Jason:
> > >
> > > On Wed, 2023-06-21 at 18:22 +0800, Jason-JH.Lin wrote:
> > > > 1. Add casting before assign to avoid the unintentional integer
> > > >    overflow or unintended sign extension.
> > > > 2. Add a int varriable for multiplier calculation instead of
> > > > calculating
> > > >    different types multiplier with dma_addr_t varriable
> directly.
> > >
> > > I agree with these modification, but the title does not match the
> > > modification.
> > >
> > > Regards,
> > > CK
> > 
> > I'll change the title and commit msg at the next version below:
> > 
> > Fix unintentional integer overflow in multiplying different types
> > 
> > 1. Instead of multiplying 2 variable of different types. Change to
> > assign a value of one variable and then multiply the other
> variable.
> > 
> > 2. Add a int variable for multiplier calculation instead of
> calculating
> > different types multiplier with dma_addr_t variable directly.
> 
> I'm pretty sure the patch makes absolutely no difference.
> In C all arithmetic is done with char/short (inc. unsigned)
> promoted to int.

`char/short promoted to int` could you give me an example or more
detail for this?
I can't really understand about that. Thanks~

> 
> So the only likely overflow is if the values exceed 2^31.
> Since the temporaries you are using are 'int' this isn't true.
> 

According to the modification:

+     int offset;
...
-             addr += (new_state->src.x1 >> 16) * fb->format->cpp[0];
-             addr += (new_state->src.y1 >> 16) * pitch;
+             offset = (new_state->src.x1 >> 16) * fb->format->cpp[0];
+             addr += offset;
+             offset = (new_state->src.y1 >> 16) * pitch;
+             addr += offset;


The main reasons why I use `int offset` here is that

src.x1 and src.y1 are `32bits int` defined in

struct drm_rect {
       int x1, y1, x2, y2;
};

We know that the values of `x1 * cpp` and `y1 * pitch` would never
cause 32bits overflow actually.

So I just add the same type `int offset` as a 32bits variable to avoid
Coverity checker catching the unintentional overflow of
`64bits addr += 32bits x1 * 8bits cpp` and
`64bits addr += 32bits y1 * 32bits pitch`.

Another reason is that using `unsined int offset` to store the
calculation result of negative x1 and y1, offset may be a very big
number because of overflow of `negative int`.

Do you agree with that?

Regards,
Jason-JH.Lin


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