CVE-2024-38570

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

gfs2: Fix potential glock use-after-free on unmount

When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didnt want to unlock and then release the lockspace. This didnt take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.

To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.

As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.

Weakness

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory “belongs” to the code that operates on the new pointer.

Affected Software

Potential Mitigations

References

• https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37
• https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca
• https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73
• https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0
• https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37
• https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca
• https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73
• https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0