linux-hardening - RE: [PATCH v3 2/2] igb: Proactively round up to kmalloc bucket size

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <DM5PR11MB1324EC38950CD47541E69EE1C1399@DM5PR11MB1324.namprd11.prod.outlook.com>
Date:   Wed, 2 Nov 2022 14:12:33 +0000
From:   "Ruhl, Michael J" <michael.j.ruhl@...el.com>
To:     Kees Cook <keescook@...omium.org>
CC:     "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        "Eric Dumazet" <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: RE: [PATCH v3 2/2] igb: Proactively round up to kmalloc bucket size

>-----Original Message-----
>From: Kees Cook <keescook@...omium.org>
>Sent: Tuesday, November 1, 2022 5:37 PM
>To: Ruhl, Michael J <michael.j.ruhl@...el.com>
>Cc: Brandeburg, Jesse <jesse.brandeburg@...el.com>; Nguyen, Anthony L
><anthony.l.nguyen@...el.com>; David S. Miller <davem@...emloft.net>;
>Eric Dumazet <edumazet@...gle.com>; Jakub Kicinski <kuba@...nel.org>;
>Paolo Abeni <pabeni@...hat.com>; intel-wired-lan@...ts.osuosl.org;
>netdev@...r.kernel.org; linux-kernel@...r.kernel.org; linux-
>hardening@...r.kernel.org
>Subject: Re: [PATCH v3 2/2] igb: Proactively round up to kmalloc bucket size
>
>On Mon, Oct 31, 2022 at 08:42:36PM +0000, Ruhl, Michael J wrote:
>> Looking at the size usage (from elixir), I see:
>>
>> --
>> 	if (!q_vector) {
>> 		q_vector = kzalloc(size, GFP_KERNEL);
>> 	} else if (size > ksize(q_vector)) {
>> 		kfree_rcu(q_vector, rcu);
>> 		q_vector = kzalloc(size, GFP_KERNEL);
>> 	} else {
>> 		memset(q_vector, 0, size);
>> 	}
>> --
>>
>> If the size is rounded up, will the (size > ksize()) check ever be true?
>>
>> I.e. have you eliminated this check (and maybe getting rid of the need for
>first patch?)?
>
>Hi!
>
>It looked like igb_alloc_q_vector() was designed to be called multiple
>times on the same q_vector (i.e. to grow its allocation size over time).
>So for that case, yes, the "size > ksize(q_vector)" check is needed. If
>it's only ever called once (which is hard for me to tell), then no. (And
>if "no", why was the alloc/free case even there in the first place?)

Ahh, Ok, I missed the fact that size is based on ring_count.  When I saw
the "struct_size" I assumed that size would be the same every time and
missed this point.

So can vary over time, and this ksize check is needed.

With that in mind these patches look good to me.

Reviewed-by: Michael J. Ruhl <michael.j.ruhl@...el.com>

Mike

>-Kees
>
>--
>Kees Cook