CVE-2024-56592

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

bpf: Call freehtabelem() after htabunlockbucket()

For htab of maps, when the map is removed from the htab, it may hold the last reference of the map. bpfmapfdputptr() will invoke bpfmapfreeid() to free the id of the removed map element. However, bpfmapfdputptr() is invoked while holding a bucket lock (rawspinlockt), and bpfmapfreeid() attempts to acquire mapidrlock (spinlockt), triggering the following lockdep warning:

============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted

testmaps/4881 is trying to lock: ffffffff84884578 (mapidrlock){+...}-{3:3}, at: bpfmapfreeid.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by testmaps/4881: #0: ffffffff846caf60 (rcureadlock){....}-{1:3}, at: bpffdhtabmapupdateelem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdepkey#2){....}-{2:2}, at: htabmapupdateelem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: testmaps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: <TASK> dumpstacklvl+0x6e/0xb0 dumpstack+0x10/0x20 _lockacquire+0x73e/0x36c0 lockacquire+0x182/0x450 _rawspinlockirqsave+0x43/0x70 bpfmapfreeid.part.0+0x21/0x70 bpfmapput+0xcf/0x110 bpfmapfdputptr+0x9a/0xb0 freehtabelem+0x69/0xe0 htabmapupdateelem+0x50f/0xa80 bpffdhtabmapupdateelem+0x131/0x270 htabmapupdateelem+0x50f/0xa80 bpffdhtabmapupdateelem+0x131/0x270 bpfmapupdatevalue+0x266/0x380 _sysbpf+0x21bb/0x36b0 _x64sysbpf+0x45/0x60 x64syscall+0x1b2a/0x20d0 dosyscall64+0x5d/0x100 entrySYSCALL64after_hwframe+0x76/0x7e

One way to fix the lockdep warning is using rawspinlockt for mapidrlock as well. However, bpfmapallocid() invokes idralloccyclic() after acquiring mapidrlock, it will trigger a similar lockdep warning because the slab's lock (s->cpuslab->lock) is still a spinlock.

Instead of changing mapidrlock's type, fix the issue by invoking htabputfdvalue() after htabunlockbucket(). However, only deferring the invocation of htabputfdvalue() is not enough, because the old map pointers in htab of maps can not be saved during batched deletion. Therefore, also defer the invocation of freehtabelem(), so these to-be-freed elements could be linked together similar to lru map.

There are four callers for ->mapfdput_ptr:

(1) allochtabelem() (through htabputfdvalue()) It invokes ->mapfdputptr() under a rawspinlockt. The invocation of htabputfdvalue() can not simply move after htabunlockbucket(), because the old element has already been stashed in htab->extraelems. It may be reused immediately after htabunlockbucket() and the invocation of htabputfdvalue() after htabunlockbucket() may release the newly-added element incorrectly. Therefore, saving the map pointer of the old element for htab of maps before unlocking the bucket and releasing the mapptr after unlock. Beside the map pointer in the old element, should do the same thing for the special fields in the old element as well.

(2) freehtabelem() (through htabputfdvalue()) Its caller includes _htabmaplookupanddeleteelem(), htabmapdeleteelem() and _htabmaplookupanddeletebatch().

For htabmapdeleteelem(), simply invoke freehtabelem() after htabunlockbucket(). For _htabmaplookupanddeletebatch(), just like lru map, linking the to-be-freed element into nodetofree list and invoking freehtabelem() for these element after unlock. It is safe to reuse batchflink as the link for nodetofree, because these elements have been removed from the hash llist.

Because htab of maps doesn't support lookupanddelete operation, _htabmaplookupanddeleteelem() doesn't have the problem, so kept it as ---truncated---