linux-hardening - Re: [PATCH] apparmor: aa_buffer: Convert 1-element array to flexible array

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <7085879d-4d21-b90a-c08d-60450d1c7d38@canonical.com>
Date:   Thu, 11 May 2023 14:48:29 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     "Gustavo A . R . Silva" <gustavoars@...nel.org>,
        Paul Moore <paul@...l-moore.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>, apparmor@...ts.ubuntu.com,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] apparmor: aa_buffer: Convert 1-element array to flexible
 array

On 5/11/23 14:34, Kees Cook wrote:
> In the ongoing effort to convert all fake flexible arrays to proper
> flexible arrays, replace aa_buffer's 1-element "buffer" member with a
> flexible array.
> 
> Cc: John Johansen <john.johansen@...onical.com>
> Cc: Gustavo A. R. Silva <gustavoars@...nel.org>
> Cc: Paul Moore <paul@...l-moore.com>
> Cc: James Morris <jmorris@...ei.org>
> Cc: "Serge E. Hallyn" <serge@...lyn.com>
> Cc: apparmor@...ts.ubuntu.com
> Cc: linux-security-module@...r.kernel.org
> Signed-off-by: Kees Cook <keescook@...omium.org>

Acked-by: John Johansen <john.johansen@...onical.com>

I have pulled this into my tree.

> ---
> One thing I notice here is that it may be rare for "buffer" to ever change
> for a given kernel. Could this just be made PATH_MAX * 2 directly and
> remove the module parameter, etc, etc?

possibly. Currently the only use case I know of is for some stress testing
where we drop the buffer size down really small to try and break things.
This isn't part of the regular regression runs and could be handle with a
config/compile time to a buffer size constant.


> ---
>   security/apparmor/lsm.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index d6cc4812ca53..35eb41bb9e3a 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -46,7 +46,7 @@ int apparmor_initialized;
>   
>   union aa_buffer {
>   	struct list_head list;
> -	char buffer[1];
> +	DECLARE_FLEX_ARRAY(char, buffer);
>   };
>   
>   #define RESERVE_COUNT 2
> @@ -1647,7 +1647,7 @@ char *aa_get_buffer(bool in_atomic)
>   		list_del(&aa_buf->list);
>   		buffer_count--;
>   		spin_unlock(&aa_buffers_lock);
> -		return &aa_buf->buffer[0];
> +		return aa_buf->buffer;
>   	}
>   	if (in_atomic) {
>   		/*
> @@ -1670,7 +1670,7 @@ char *aa_get_buffer(bool in_atomic)
>   		pr_warn_once("AppArmor: Failed to allocate a memory buffer.\n");
>   		return NULL;
>   	}
> -	return &aa_buf->buffer[0];
> +	return aa_buf->buffer;
>   }
>   
>   void aa_put_buffer(char *buf)
> @@ -1747,7 +1747,7 @@ static int __init alloc_buffers(void)
>   			destroy_buffers();
>   			return -ENOMEM;
>   		}
> -		aa_put_buffer(&aa_buf->buffer[0]);
> +		aa_put_buffer(aa_buf->buffer);
>   	}
>   	return 0;
>   }