On 7/10/24 01:28, Kees Cook wrote:
On Tue, Jul 09, 2024 at 11:02:55PM +0200, Marco Elver wrote:
On Tue, 9 Jul 2024 at 22:28, Kees Cook wrote:
On Tue, Jul 09, 2024 at 10:26:32AM -0700, Christoph Lameter (Ampere) wrote:
On Mon, 8 Jul 2024, Kees Cook wrote:
obj = kmalloc(obj, gfp
Replace the depreciated[1] strncpy() calls with strscpy(). Uses of
object->comm do not depend on the padding side-effect.
Link: https://github.com/KSPP/linux/issues/90 [1]
Signed-off-by: Kees Cook
---
Cc: Catalin Marinas
Cc: Andrew Morton
Cc: linux...@kvack.org
---
mm/kmemleak.c | 6 +++---
1
On Tue, Jul 09, 2024 at 11:02:55PM +0200, Marco Elver wrote:
> On Tue, 9 Jul 2024 at 22:28, Kees Cook wrote:
> >
> > On Tue, Jul 09, 2024 at 10:26:32AM -0700, Christoph Lameter (Ampere) wrote:
> > > On Mon, 8 Jul 2024, Kees Cook wrote:
> > >
> > > >
> > > >obj = kmalloc(obj, gfp);
> >
On Tue, 9 Jul 2024 at 22:28, Kees Cook wrote:
>
> On Tue, Jul 09, 2024 at 10:26:32AM -0700, Christoph Lameter (Ampere) wrote:
> > On Mon, 8 Jul 2024, Kees Cook wrote:
> >
> > >
> > >obj = kmalloc(obj, gfp);
> >
> > Could we avoid repeating "obj" in this pattern?
> >
> > F.e.
> >
> >
On Tue, Jul 09, 2024 at 01:19:44PM -0700, Breno Leitao wrote:
> On Tue, Jul 09, 2024 at 07:11:28PM +0100, Simon Horman wrote:
> > Flagged by: kernel-doc -none
>
> How do you run this test exactly? I would like to add to my workflow.
Details here:
https://docs.kernel.org/doc-guide/kernel-doc.html
On Tue, Jul 09, 2024 at 10:26:32AM -0700, Christoph Lameter (Ampere) wrote:
> On Mon, 8 Jul 2024, Kees Cook wrote:
>
> >
> >obj = kmalloc(obj, gfp);
>
> Could we avoid repeating "obj" in this pattern?
>
> F.e.
>
> KMALLOC(obj, gfp);
This appears to be the common feedback, wh
On Tue, Jul 09, 2024 at 08:27:45AM -0700, Eric Dumazet wrote:
> On Tue, Jul 9, 2024 at 5:54 AM Breno Leitao wrote:
> > @@ -2596,7 +2599,7 @@ void dev_net_set(struct net_device *dev, struct net
> > *net)
> > */
> > static inline void *netdev_priv(const struct net_device *dev)
> > {
> > -
On Tue, Jul 09, 2024 at 07:11:28PM +0100, Simon Horman wrote:
> On Tue, Jul 09, 2024 at 05:54:25AM -0700, Breno Leitao wrote:
> > From: Alexander Lobakin
> >
> > In fact, this structure contains a flexible array at the end, but
> > historically its size, alignment etc., is calculated manually.
>
On Tue, Jul 09, 2024 at 04:57:38PM +, Roman Gushchin wrote:
> On Mon, Jul 08, 2024 at 12:18:34PM -0700, Kees Cook wrote:
> > Hi,
> >
> > This is an RFC for some changes I'd like to make to the kernel's
> > allocators (starting with slab) that allow for type introspection, which
> > has been a
On 09/07/24 12:20, Mirsad Todorovac wrote:
On 7/9/24 01:44, Gustavo A. R. Silva wrote:
On 7/8/24 14:22, Kees Cook wrote:
Modern (fortified) memcpy() prefers to avoid writing (or reading) beyond
the end of the addressed destination (or source) struct member:
In function ‘fortify_memcpy_c
On 7/9/24 01:44, Gustavo A. R. Silva wrote:
>
>
> On 7/8/24 14:22, Kees Cook wrote:
>> Modern (fortified) memcpy() prefers to avoid writing (or reading) beyond
>> the end of the addressed destination (or source) struct member:
>>
>> In function ‘fortify_memcpy_chk’,
>> inlined from ‘sysca
On Tue, Jul 09, 2024 at 05:54:25AM -0700, Breno Leitao wrote:
> From: Alexander Lobakin
>
> In fact, this structure contains a flexible array at the end, but
> historically its size, alignment etc., is calculated manually.
> There are several instances of the structure embedded into other
> struc
On Mon, 8 Jul 2024, Kees Cook wrote:
obj = kmalloc(obj, gfp);
Could we avoid repeating "obj" in this pattern?
F.e.
KMALLOC(obj, gfp);
instead?
On Mon, Jul 08, 2024 at 12:18:34PM -0700, Kees Cook wrote:
> Hi,
>
> This is an RFC for some changes I'd like to make to the kernel's
> allocators (starting with slab) that allow for type introspection, which
> has been a long-time gap in potential analysis capabilities available
> at compile-time
On Tue, Jul 09, 2024 at 09:06:58AM +0200, Przemek Kitszel wrote:
> On 7/8/24 21:18, Kees Cook wrote:
> > diff --git a/fs/pstore/blk.c b/fs/pstore/blk.c
> > index de8cf5d75f34..7bb9cacb380f 100644
> > --- a/fs/pstore/blk.c
> > +++ b/fs/pstore/blk.c
> > @@ -297,7 +297,7 @@ static int __init __best_ef
On Tue, Jul 09, 2024 at 08:57:55AM +0200, Przemek Kitszel wrote:
> On 7/8/24 21:18, Kees Cook wrote:
> > The allocator will already reject giant sizes seen from negative size
> > arguments, so this commit mainly services as an example for initial
> > type-based filtering. The size argument is check
On Tue, Jul 09, 2024 at 05:54:25AM -0700, Breno Leitao wrote:
> From: Alexander Lobakin
>
> In fact, this structure contains a flexible array at the end, but
> historically its size, alignment etc., is calculated manually.
> There are several instances of the structure embedded into other
> struc
Since the beginning of time, struct usb_ep::maxpacket was a bitfield,
and when new 16-bit members were added, the convention was followed:
1da177e4c3f41 (Linus Torvalds 2005-04-16 236) unsigned maxpacket:16;
e117e742d3106 (Robert Baldyga 2013-12-13 237) unsigned maxpacket_limit:16;
a59d6b91cbc
On Tue, Jul 9, 2024 at 5:54 AM Breno Leitao wrote:
>
> From: Alexander Lobakin
>
> In fact, this structure contains a flexible array at the end, but
> historically its size, alignment etc., is calculated manually.
> There are several instances of the structure embedded into other
> structures, bu
From: Alexander Lobakin
In fact, this structure contains a flexible array at the end, but
historically its size, alignment etc., is calculated manually.
There are several instances of the structure embedded into other
structures, but also there's ongoing effort to remove them and we
could in the
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Justin Stitt
[ Upstream commit efb905aeb44b0e99c0e6b07865b1885ae0471ebf ]
When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:
[ 366.01595
6.9-stable review patch. If anyone has any objections, please let me know.
--
From: Justin Stitt
[ Upstream commit efb905aeb44b0e99c0e6b07865b1885ae0471ebf ]
When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:
[ 366.01595
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Justin Stitt
[ Upstream commit efb905aeb44b0e99c0e6b07865b1885ae0471ebf ]
When running syzkaller with the newly reintroduced signed integer wrap
sanitizer we encounter this splat:
[ 366.01595
Le 09/07/2024 à 11:39, Greg KH a écrit :
> On Tue, Jul 09, 2024 at 09:24:54AM +, LEROY Christophe wrote:
>>
>>
>> Le 09/07/2024 à 11:15, Greg KH a écrit :
>>> On Mon, Jul 08, 2024 at 03:12:55PM +, LEROY Christophe wrote:
Le 08/07/2024 à 14:36, Greg KH a écrit :
> On Sun
On Tue, Jul 09, 2024 at 09:24:54AM +, LEROY Christophe wrote:
>
>
> Le 09/07/2024 à 11:15, Greg KH a écrit :
> > On Mon, Jul 08, 2024 at 03:12:55PM +, LEROY Christophe wrote:
> >>
> >>
> >> Le 08/07/2024 à 14:36, Greg KH a écrit :
> >>> On Sun, Jul 07, 2024 at 03:34:15PM +0800, WangYuli w
Le 09/07/2024 à 11:15, Greg KH a écrit :
> On Mon, Jul 08, 2024 at 03:12:55PM +, LEROY Christophe wrote:
>>
>>
>> Le 08/07/2024 à 14:36, Greg KH a écrit :
>>> On Sun, Jul 07, 2024 at 03:34:15PM +0800, WangYuli wrote:
On 2024/7/6 17:30, Greg KH wrote:
> This makes it sound like y
On Mon, Jul 08, 2024 at 03:12:55PM +, LEROY Christophe wrote:
>
>
> Le 08/07/2024 à 14:36, Greg KH a écrit :
> > On Sun, Jul 07, 2024 at 03:34:15PM +0800, WangYuli wrote:
> >>
> >> On 2024/7/6 17:30, Greg KH wrote:
> >>> This makes it sound like you are reverting this because of a build
> >>>
On 7/8/24 21:18, Kees Cook wrote:
Using a short Coccinelle script, it is possible to replace the classic
kmalloc code patterns with the typed information:
@alloc@
type TYPE;
TYPE *P;
expression GFP;
identifier ALLOC =~ "k[mz]alloc";
@@
P = ALLOC(
- \(sizeof(*P)\|sizeof(TYP
28 matches
Mail list logo
