On 1/14/26 15:06, Tyler Hicks wrote:
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?
good catch, atm that is indeed the case
