From: Daniel Micay
The vDSO (and its initial randomization) was introduced in commit
2aae950b21e4 ("x86_64: Add vDSO for x86-64 with
gettimeofday/clock_gettime/getcpu"),
but had very low entropy. The entropy was improved in commit
394f56fe4801 ("x86_64, vdso: Fix the vdso address randomization a
On Thu, 8 Feb 2024, Lee Jones wrote:
> On Thu, 08 Feb 2024, Geert Uytterhoeven wrote:
>
> >
> > Confused... The return value is not used at all?
>
> Future proofing.
>
Surely a better way to prevent potential future API abuse is by adding
checkpatch.pl rules. That way does not generate ch
From: Kees Cook
> Sent: 07 February 2024 09:19
>
> On Wed, Feb 07, 2024 at 12:51:51AM +, Justin Stitt wrote:
> > Hi,
> >
> > On Tue, Feb 06, 2024 at 06:22:18AM -0800, Kees Cook wrote:
> > > Similar to strscpy(), update strscpy_pad()'s 3rd argument to be
> > > optional when the destination is a
On Thu, 2024-02-08 at 10:29 +, Lee Jones wrote:
> On Thu, 08 Feb 2024, Geert Uytterhoeven wrote:
>
> > Hi Lee,
> >
> > Thanks for your patch!
> >
> > On Thu, Feb 8, 2024 at 9:48 AM Lee Jones wrote:
> > > There is a general misunderstanding amongst engineers that
> > > {v}snprintf()
> > > re
From: Pavel Machek
> Sent: 07 February 2024 17:52
>
> > > Using sizeof(dst) is the overwhelmingly common case for strscpy().
> > > Instead of requiring this everywhere, allow a 2-argument version to be
> > > used that will use the sizeof() internally.
> >
> > Yeah, this is definitely the case. I h
From: Pavel Machek
> Sent: 07 February 2024 17:52
> > > Using sizeof(dst) is the overwhelmingly common case for strscpy().
> > > Instead of requiring this everywhere, allow a 2-argument version to be
> > > used that will use the sizeof() internally.
> >
> > Yeah, this is definitely the case. I have
This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1].
As the "chip" variable is a pointer to "struct mtk_nfc_nand_chip" and
this structure ends in a flexible array:
struct mtk_nfc_nand_chip {
[...]
u8 sels[] __coun
On 2/10/24 10:16, Erick Archer wrote:
This is an effort to get rid of all multiplications from allocation
functions in order to prevent integer overflows [1].
As the "chip" variable is a pointer to "struct mtk_nfc_nand_chip" and
this structure ends in a flexible array:
struct mtk_nfc_nand_ch
On Sat, Feb 10, 2024 at 05:16:19PM +0100, Erick Archer wrote:
> This is an effort to get rid of all multiplications from allocation
> functions in order to prevent integer overflows [1].
>
> As the "chip" variable is a pointer to "struct mtk_nfc_nand_chip" and
> this structure ends in a flexible a
On Fri, 2024-02-09 at 22:56 -0800, Kees Cook wrote:
> On Thu, Feb 08, 2024 at 05:49:12PM +, Lee Jones wrote:
> > On Thu, 08 Feb 2024, Bart Van Assche wrote:
> >
> > > On 2/8/24 00:44, Lee Jones wrote:
> > > > Cc: Andre Hedrick
> > >
> > > Please take a look at https://lwn.net/Articles/508222
We are trying to get rid of all multiplications from allocation
functions to prevent integer overflows[1]. Here the multiplication is
obviously safe, but using kcalloc() is more appropriate and improves
readability. This patch has no effect on runtime behavior.
Link: https://github.com/KSPP/linux/
On 2/10/24 19:53, Lenko Donchev wrote:
We are trying to get rid of all multiplications from allocation
functions to prevent integer overflows[1]. Here the multiplication is
obviously safe, but using kcalloc() is more appropriate and improves
readability. This patch has no effect on runtime beh
12 matches
Mail list logo
