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 <[email protected]> > --- > 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 > >
