[apparmor] [PATCH] apparmor: fix boolean argument in apparmor_mmap_file

[Tyler Hicks]

On 2026-01-14 09:32:24, Ryan Lee wrote:
> The previous value of GFP_ATOMIC is an int and not a bool, potentially
> resulting in UB when being assigned to a bool. In addition, the mmap hook
> is called outside of locks (i.e. in a non-atomic context), so we can pass
> a fixed constant value of false instead to common_mmap.
> 
> Signed-off-by: Ryan Lee <ryan.lee at canonical.com>
> ---
>  security/apparmor/lsm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 08757f372972..320e4e1e1748 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -826,7 +826,7 @@ static int common_mmap(const char *op, struct file *file, unsigned long prot,
>  static int apparmor_mmap_file(struct file *file, unsigned long reqprot,
>  			      unsigned long prot, unsigned long flags)
>  {
> -	return common_mmap(OP_FMMAP, file, prot, flags, GFP_ATOMIC);
> +	return common_mmap(OP_FMMAP, file, prot, flags, false);

With all callers of common_mmap() now passing false for in_atomic,
shouldn't we drop in_atomic from the common_mmap() function definition?

Tyler

>  }
>  
>  static int apparmor_file_mprotect(struct vm_area_struct *vma,
> -- 
> 2.43.0
> 
>