[PATCH v2][next] cgroup: Avoid -Wstringop-overflow warnings

[PATCH v2][next] cgroup: Avoid -Wstringop-overflow warnings

[Gustavo A. R. Silva]

Change the notation from pointer-to-array to pointer-to-pointer.
With this, we avoid the compiler complaining about trying
to access a region of size zero as an argument during function
calls.

Address the following -Wstringop-overflow warnings seen when
built with ARM architecture and aspeed_g4_defconfig configuration
(notice that under this configuration CGROUP_SUBSYS_COUNT == 0):

kernel/cgroup/cgroup.c:1208:16: warning: 'find_existing_css_set' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=]
kernel/cgroup/cgroup.c:1258:15: warning: 'css_set_hash' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=]
kernel/cgroup/cgroup.c:6089:18: warning: 'css_set_hash' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=]
kernel/cgroup/cgroup.c:6153:18: warning: 'css_set_hash' accessing 4 bytes in a region of size 0 [-Wstringop-overflow=]

This results in no differences in binary output.

Link: https://github.com/KSPP/linux/issues/316
Signed-off-by: Gustavo A. R. Silva <gustavoars-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v2:
 - Use pointer-to-pointer instead of pointer-to-array.
 - Update changelog text.

v1:
 - Link: https://lore.kernel.org/linux-hardening/ZIpm3pcs3iCP9UaR@work/

 kernel/cgroup/cgroup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index ccbbba06da5b..68e2d9812e3f 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -929,7 +929,7 @@ static void css_set_move_task(struct task_struct *task,
 #define CSS_SET_HASH_BITS	7
 static DEFINE_HASHTABLE(css_set_table, CSS_SET_HASH_BITS);
 
-static unsigned long css_set_hash(struct cgroup_subsys_state *css[])
+static unsigned long css_set_hash(struct cgroup_subsys_state **css)
 {
 	unsigned long key = 0UL;
 	struct cgroup_subsys *ss;
@@ -1070,7 +1070,7 @@ static bool compare_css_sets(struct css_set *cset,
  */
 static struct css_set *find_existing_css_set(struct css_set *old_cset,
 					struct cgroup *cgrp,
-					struct cgroup_subsys_state *template[])
+					struct cgroup_subsys_state **template)
 {
 	struct cgroup_root *root = cgrp->root;
 	struct cgroup_subsys *ss;
-- 
2.34.1

Re: [PATCH v2][next] cgroup: Avoid -Wstringop-overflow warnings

[Tejun Heo]

Hello,

On Wed, Aug 16, 2023 at 02:50:16PM -0600, Gustavo A. R. Silva wrote:
> Change the notation from pointer-to-array to pointer-to-pointer.
> With this, we avoid the compiler complaining about trying
> to access a region of size zero as an argument during function
> calls.

Haha, I thought the functions were actually accessing the memory. This can't
be an intended behavior on the compiler's side, right?

Thanks.

-- 
tejun

Re: [PATCH v2][next] cgroup: Avoid -Wstringop-overflow warnings

[Kees Cook]

On Wed, Aug 16, 2023 at 10:51:12AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Wed, Aug 16, 2023 at 02:50:16PM -0600, Gustavo A. R. Silva wrote:
> > Change the notation from pointer-to-array to pointer-to-pointer.
> > With this, we avoid the compiler complaining about trying
> > to access a region of size zero as an argument during function
> > calls.
> 
> Haha, I thought the functions were actually accessing the memory. This can't
> be an intended behavior on the compiler's side, right?

I think it's a result of inlining -- the compiler ends up with a case
where it looks like it might be possible to index a zero-sized array,
but it is "accidentally safe".

-- 
Kees Cook

Re: [PATCH v2][next] cgroup: Avoid -Wstringop-overflow warnings

[Tejun Heo]

On Wed, Aug 16, 2023 at 01:57:16PM -0700, Kees Cook wrote:
> On Wed, Aug 16, 2023 at 10:51:12AM -1000, Tejun Heo wrote:
> > Hello,
> > 
> > On Wed, Aug 16, 2023 at 02:50:16PM -0600, Gustavo A. R. Silva wrote:
> > > Change the notation from pointer-to-array to pointer-to-pointer.
> > > With this, we avoid the compiler complaining about trying
> > > to access a region of size zero as an argument during function
> > > calls.
> > 
> > Haha, I thought the functions were actually accessing the memory. This can't
> > be an intended behavior on the compiler's side, right?
> 
> I think it's a result of inlining -- the compiler ends up with a case
> where it looks like it might be possible to index a zero-sized array,
> but it is "accidentally safe".

Ah I see. It's not that the compiler knows that ** access is safe. It's more
that it only applies the check on arrays. Is that right? Gustavo, I don't
mind the patch but can you update the patch description a bit explaining a
bit more on what's going on with the complier? It doesn't have to be the
full explanation but it'd be useful to explicitly point out that we're just
working around the compiler being a bit silly.

Thanks.

-- 
tejun

Re: [PATCH v2][next] cgroup: Avoid -Wstringop-overflow warnings

[Gustavo A. R. Silva]

On 8/16/23 15:01, Tejun Heo wrote:
> On Wed, Aug 16, 2023 at 01:57:16PM -0700, Kees Cook wrote:
>> On Wed, Aug 16, 2023 at 10:51:12AM -1000, Tejun Heo wrote:
>>> Hello,
>>>
>>> On Wed, Aug 16, 2023 at 02:50:16PM -0600, Gustavo A. R. Silva wrote:
>>>> Change the notation from pointer-to-array to pointer-to-pointer.
>>>> With this, we avoid the compiler complaining about trying
>>>> to access a region of size zero as an argument during function
>>>> calls.
>>>
>>> Haha, I thought the functions were actually accessing the memory. This can't
>>> be an intended behavior on the compiler's side, right?
>>
>> I think it's a result of inlining -- the compiler ends up with a case
>> where it looks like it might be possible to index a zero-sized array,
>> but it is "accidentally safe".
> 
> Ah I see. It's not that the compiler knows that ** access is safe. It's more
> that it only applies the check on arrays. Is that right? Gustavo, I don't

That's correct.

> mind the patch but can you update the patch description a bit explaining a
> bit more on what's going on with the complier? It doesn't have to be the
> full explanation but it'd be useful to explicitly point out that we're just
> working around the compiler being a bit silly.

I just sent v3:

	https://lore.kernel.org/linux-hardening/ZN5WkbPelHUSTXOA@work/

Thanks
--
Gustavo