On Sun, Jan 14, 2024 at 11:53:40AM +0100, Erick Archer wrote:
> Use 2-factor multiplication argument form kcalloc() instead
> of kzalloc().
>
> Link: https://github.com/KSPP/linux/issues/162
> Signed-off-by: Erick Archer
Could you put something in the commit message explaining *why* this change
Hey, I read that ASLR is currently (since kernel >=5.18) broken for
32bit libs and reduced in effectiveness for 64bit libs... (the issue
only arises if a lib is over 2MB).
I confirmed this for myself but only for the 64bit case.
I saw that this issue is being tracked by ubuntu
(https://bugs.la
m...@horotw.com writes:
> Hey, I read that ASLR is currently (since kernel >=5.18) broken for
> 32bit libs and reduced in effectiveness for 64bit libs... (the issue
> only arises if a lib is over 2MB).
> I confirmed this for myself but only for the 64bit case.
>
> I saw that this issue is being
On Mon, Jan 15, 2024 at 04:40:36PM +, Sam James wrote:
> m...@horotw.com writes:
> > Hey, I read that ASLR is currently (since kernel >=5.18) broken for
> > 32bit libs and reduced in effectiveness for 64bit libs... (the issue
> > only arises if a lib is over 2MB).
> > I confirmed this for mysel
As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them overflowing. This could lead
to values wrappin
On 1/15/24 12:16, Erick Archer wrote:
As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them ove
On 1/14/24 04:24, Erick Archer wrote:
Use 2-factor multiplication argument form kcalloc() instead
of kzalloc().
Also, it is preferred to use sizeof(*pointer) instead of
sizeof(type) due to the type of the variable can change and
one needs not change the former (unlike the latter).
Link: http
Am 15.01.2024 17:52, schrieb Matthew Wilcox:
On Mon, Jan 15, 2024 at 04:40:36PM +, Sam James wrote:
m...@horotw.com writes:
> Hey, I read that ASLR is currently (since kernel >=5.18) broken for
> 32bit libs and reduced in effectiveness for 64bit libs... (the issue
> only arises if a lib is o
On Mon, Jan 15, 2024 at 07:21:19PM +0100, m...@horotw.com wrote:
> Am 15.01.2024 17:52, schrieb Matthew Wilcox:
> > On Mon, Jan 15, 2024 at 04:40:36PM +, Sam James wrote:
> > > m...@horotw.com writes:
> > > > Hey, I read that ASLR is currently (since kernel >=5.18) broken for
> > > > 32bit libs
From: Dmitry Antipov
[ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ]
When compiling with gcc version 14.0.0 20231126 (experimental)
and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
In file included from ./include/linux/string.h:295,
from ./include/linux/bit
From: Dmitry Antipov
[ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ]
When compiling with gcc version 14.0.0 20231126 (experimental)
and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
In file included from ./include/linux/string.h:295,
from ./include/linux/bit
From: Dmitry Antipov
[ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ]
When compiling with gcc version 14.0.0 20231126 (experimental)
and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
In file included from ./include/linux/string.h:295,
from ./include/linux/bit
From: Dmitry Antipov
[ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ]
When compiling with gcc version 14.0.0 20231126 (experimental)
and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
In file included from ./include/linux/string.h:295,
from ./include/linux/bit
From: Dmitry Antipov
[ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ]
When compiling with gcc version 14.0.0 20231126 (experimental)
and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
In file included from ./include/linux/string.h:295,
from ./include/linux/bit
From: Dmitry Antipov
[ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ]
When compiling with gcc version 14.0.0 20231126 (experimental)
and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
In file included from ./include/linux/string.h:295,
from ./include/linux/bit
From: Dmitry Antipov
[ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ]
When compiling with gcc version 14.0.0 20231126 (experimental)
and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
In file included from ./include/linux/string.h:295,
from ./include/linux/bit
From: Weichen Chen
[ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ]
When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
addr of zone0 = BASE
addr of zone1 = BASE + zone_size
addr
From: Weichen Chen
[ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ]
When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
addr of zone0 = BASE
addr of zone1 = BASE + zone_size
addr
From: Weichen Chen
[ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ]
When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
addr of zone0 = BASE
addr of zone1 = BASE + zone_size
addr
From: Weichen Chen
[ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ]
When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
addr of zone0 = BASE
addr of zone1 = BASE + zone_size
addr
From: Weichen Chen
[ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ]
When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
addr of zone0 = BASE
addr of zone1 = BASE + zone_size
addr
From: Weichen Chen
[ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ]
When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
addr of zone0 = BASE
addr of zone1 = BASE + zone_size
addr
From: Weichen Chen
[ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ]
When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
addr of zone0 = BASE
addr of zone1 = BASE + zone_size
addr
23 matches
Mail list logo
