linux-hardening - RE: [GIT PULL] Enable -Wstringop-overflow globally

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: <f00e15fcba05497a87e91182a33c888f@AcuMS.aculab.com>
Date: Sat, 27 Jan 2024 15:11:11 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Linus Torvalds' <torvalds@...ux-foundation.org>, Kees Cook
	<keescook@...omium.org>
CC: "Gustavo A. R. Silva" <gustavo@...eddedor.com>, "Gustavo A. R. Silva"
	<gustavoars@...nel.org>, "linux-hardening@...r.kernel.org"
	<linux-hardening@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [GIT PULL] Enable -Wstringop-overflow globally

From: Linus Torvalds
> Sent: 26 January 2024 22:36
> 
> On Fri, 26 Jan 2024 at 14:24, Kees Cook <keescook@...omium.org> wrote:
> >
> > I think xe has some other weird problems too. This may be related (under
> > allocating):
> >
> > ../drivers/gpu/drm/xe/xe_vm.c: In function 'xe_vma_create':
> > ../drivers/gpu/drm/xe/xe_vm.c:806:21: warning: allocation of insufficient size '224' for type
> 'struct xe_vma' with size '368' [-Walloc-size]
> >   806 |                 vma = kzalloc(sizeof(*vma) - sizeof(struct xe_userptr),
> >       |                     ^
> 
> That code is indeed odd, but there's a comment in the xe_vma definition
> 
>         /**
>          * @userptr: user pointer state, only allocated for VMAs that are
>          * user pointers
>          */
>         struct xe_userptr userptr;
> 
> although I agree that it should probably simply be made a final
> variably-sized array instead (and then you make that array size be
> 0/1).

That entire code is odd.
It isn't obvious that the flag values that cause the short allocate
are the same ones that control whether the extra data is accessed.

Never mind the oddities with the 'flags |= ' assignments int the
'remap next' path.

Anyone know how many of these actually get allocated (and their
lifetimes)?
How much difference would it make to allocate 368 (maybe 384?)
bytes instead of 224 (likely 256).

	David

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