CVE-2024-53222 is a vulnerability identified in the Linux kernel's zram module, specifically related to a NULL pointer dereference in the comp_algorithm_show() function. The zram module provides compressed RAM-based block devices, which are often used to improve system performance by compressing pages in memory. The vulnerability arises because the zram->comp_algs[ZRAM_PRIMARY_COMP] pointer can be NULL during the initialization phase in zram_add() if comp_algorithm_set() has not yet been called. This creates a race condition where a user can access the zram device via sysfs after device_add_disk() has been called but before the compression algorithm is properly set, leading to a NULL pointer dereference when comp_algorithm_show() attempts to access this pointer. The kernel stack trace indicates that this occurs during a sysfs read operation, which is typically accessible to unprivileged users. The root cause is that comp_algorithm_set() is protected by zram->init_lock in other parts of the code, but the ordering of calls in zram_add() allowed a time window where the device was accessible but not fully initialized. The fix involves moving the comp_algorithm_set() call ahead of device_add_disk(), ensuring that when the device is exposed to userspace, it is fully initialized and the pointer is valid. This vulnerability can cause a kernel crash (denial of service) due to the NULL pointer dereference. There is no indication that this vulnerability allows privilege escalation or arbitrary code execution. No known exploits are reported in the wild as of the publication date. The vulnerability affects Linux kernel version 6.12.0-rc6+ and possibly other versions with similar zram code structure prior to the fix. The vulnerability was reported by the Linux Test Project (LTP) and is confirmed by kernel developers.

For European organizations, the primary impact of CVE-2024-53222 is the potential for denial of service (DoS) on Linux systems utilizing the zram module. Systems that rely on zram for memory compression, such as embedded devices, virtual machines, or servers optimized for memory usage, could experience kernel panics or crashes if an attacker triggers this vulnerability. Although exploitation requires access to the sysfs interface of the zram device, which may be restricted, unprivileged local users or attackers who have gained limited access could cause system instability or downtime. This could disrupt critical services, especially in environments with high availability requirements such as financial institutions, healthcare providers, or industrial control systems. Since the vulnerability does not appear to allow privilege escalation or remote code execution, the confidentiality and integrity of data are less likely to be directly impacted. However, repeated crashes could be leveraged as part of a broader attack strategy to degrade system reliability or availability. Organizations running Linux kernels with zram enabled in cloud infrastructure, virtualized environments, or container hosts should be particularly vigilant, as these environments often expose sysfs interfaces and may have multiple users or tenants. The lack of known exploits reduces immediate risk, but the vulnerability should be addressed promptly to prevent potential abuse.

1. Apply the official Linux kernel patch that reorders the initialization sequence in the zram module, ensuring comp_algorithm_set() is called before device_add_disk(). This is the definitive fix and should be prioritized in kernel updates. 2. If immediate patching is not possible, restrict access to the sysfs interface for zram devices by adjusting permissions or using Linux security modules (e.g., SELinux, AppArmor) to limit unprivileged user access to /sys/block/zram* paths. 3. Monitor kernel logs for signs of NULL pointer dereference crashes related to zram and investigate any unexpected kernel panics. 4. For virtualized or containerized environments, ensure that guest or container users do not have unnecessary access to sysfs interfaces that expose zram devices. 5. Implement robust system monitoring and alerting to detect abnormal system restarts or crashes that could indicate exploitation attempts. 6. Review and harden local user privileges to minimize the risk of unprivileged users triggering the vulnerability. 7. Engage with Linux distribution vendors to obtain timely kernel updates and security advisories relevant to this vulnerability.