In the Linux kernel, a critical vulnerability (CVE-2024-45000) has been addressed that previously plagued the fs/netfs/fscache_cookie component, which is responsible for optimally caching and managing file data received over a network.
The vulnerability lies in a missing "n_accesses" check, which is a counter to track the number of times a cookie is accessed. This missing check leads to a NULL pointer dereference bug, causing a crash in the kernel.
The kernel crash trace
BUG: kernel NULL pointer dereference, address: 0000000000000008
#PF: supervisor read access in kernel mode
[...]
RIP: 001:cachefiles_prepare_write+x30/xa
The problem occurs when the fscache_cookie_state_machine() function is still running while another process invokes fscache_unuse_cookie(). This leads to a call to fscache_cookie_lru_do_one(), which sets the FSCACHE_COOKIE_DO_LRU_DISCARD flag. This flag is then picked up by fscache_cookie_state_machine(), which attempts to withdraw the cookie via cachefiles_withdraw_cookie() and clears the cookie->cache_priv field.
Simultaneously, another process invokes cachefiles_prepare_write(). This causes a NULL pointer in the following code line:
struct cachefiles_object *object = cachefiles_cres_object(cres);
And subsequently, a crash in the next line
struct cachefiles_cache *cache = object->volume->cache;
The missing "n_accesses" check allows for the cookie to be withdrawn even when its counter is non-zero. This patch adds the missing check, ensuring that the cookie cannot be withdrawn until the counter drops to zero:
- Original patch for the issue
- Linux Kernel Mailing List (LKML) discussion on the issue
- More info on fscache_cookie
With this patch in place, the fscache_cookie_state_machine() function now properly handles pending FSCACHE_COOKIE_DO_LRU_DISCARD flags when the "n_accesses" counter is non-zero, preventing kernel crashes due to NULL pointer dereference bugs in the fs/netfs/fscache_cookie component.
It is strongly recommended that affected Linux users and administrators apply this patch as soon as possible to protect their systems from potential crashes and other related issues caused by this vulnerability.
Timeline
Published on: 09/04/2024 20:15:08 UTC
Last modified on: 09/06/2024 16:27:31 UTC