CVE-2025-39886

In the Linux kernel, the following vulnerability has been resolved:

bpf: Tell memcg to use allowspinning=false path in bpftimer_init()

Currently, calling bpfmapkmallocnode() from _bpfasyncinit() can cause various locking issues; see the following stack trace (edited for style) as one example:

... [10.011566] dorawspinlock.cold [10.011570] trytowakeup (5) double-acquiring the same [10.011575] kickpool rqlock, causing a hardlockup [10.011579] queuework [10.011582] queueworkon [10.011585] kernfsnotify [10.011589] cgroupfilenotify [10.011593] trychargememcg (4) memcg accounting raises an [10.011597] objcgroupchargepages MEMCGMAX event [10.011599] objcgroupchargeaccount [10.011600] _memcgslabpostallochook [10.011603] _kmallocnodenoprof ... [10.011611] bpfmapkmallocnode [10.011612] _bpfasyncinit [10.011615] bpftimerinit (3) BPF calls bpftimerinit() [10.011617] bpfprogxxxxxxxxxxxxxxxxfcgrunnable [10.011619] bpfschedextopsrunnable [10.011620] enqueuetaskscx (2) BPF runs with rqlock held [10.011622] enqueuetask [10.011626] ttwudoactivate [10.011629] schedttwupending (1) grabs rq_lock ...

The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/schedext/scxflatcg.bpf.c to call bpftimerinit() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpftimerinit() call more likely to raise an MEMCG_MAX event.

We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroupfileknlock, the same workerpool::lock, etc.

As suggested by Shakeel, fix this by using _GFPHIGH instead of GFPATOMIC in _bpfasyncinit(), so that e.g. if trychargememcg() raises an MEMCGMAX event, we call _memcgmemoryevent() with @allowspinning=false and avoid calling cgroupfile_notify() there.

Depends on mm patch "memcg: skip cgroupfilenotify if spinning is not allowed": https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/

v0 approach s/bpfmapkmallocnode/bpfmem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 approach: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/