CVE-2024-26609 in Linux
Summary
by MITRE • 03/11/2024
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject QUEUE/DROP verdict parameters
This reverts commit e0abdadcc6e1.
core.c:nf_hook_slow assumes that the upper 16 bits of NF_DROP verdicts contain a valid errno, i.e. -EPERM, -EHOSTUNREACH or similar, or 0.
Due to the reverted commit, its possible to provide a positive value, e.g. NF_ACCEPT (1), which results in use-after-free.
Its not clear to me why this commit was made.
NF_QUEUE is not used by nftables; "queue" rules in nftables will result in use of "nft_queue" expression.
If we later need to allow specifiying errno values from userspace (do not know why), this has to call NF_DROP_GETERR and check that "err <= 0" holds true.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/12/2024
The vulnerability in question involves a critical flaw within the Linux kernel's netfilter subsystem, specifically affecting the nftables implementation. This issue stems from improper handling of verdict parameters in the nf_tables framework where QUEUE and DROP verdicts were incorrectly processed, leading to potential security risks including use-after-free conditions. The problem was introduced through a specific commit that altered how verdict values are interpreted within the kernel's networking stack, creating a scenario where positive integer values could be passed where only negative error codes were expected.
The technical root cause lies in the core.c file's nf_hook_slow function which makes assumptions about the upper 16 bits of NF_DROP verdicts containing valid errno values that are typically negative such as -EPERM or -EHOSTUNREACH. When the reverted commit allowed positive values like NF_ACCEPT (which equals 1) to be used in these contexts, it created a dangerous situation where memory could be accessed after being freed. This particular flaw aligns with CWE-416, representing an use-after-free vulnerability that can lead to arbitrary code execution or system instability.
The operational impact of this vulnerability is significant within Linux environments utilizing netfilter and nftables for network packet filtering and manipulation. Attackers could potentially exploit this weakness by crafting malicious packet filtering rules that leverage the improper verdict handling to trigger memory corruption, potentially leading to privilege escalation or denial-of-service conditions. The vulnerability affects systems where nftables is actively used for network management, particularly in server environments where robust network filtering is essential.
This issue demonstrates a fundamental problem in kernel space validation where user-provided parameters were not adequately checked before being processed in critical system functions. The fix involves reverting the problematic commit that allowed improper verdict values to be accepted, restoring the original behavior that strictly enforces negative errno values for DROP verdicts. According to ATT&CK framework category T1068, this represents a privilege escalation vector through kernel vulnerabilities, while the specific technique relates to exploitation of memory corruption flaws in system-level components.
The mitigation approach requires careful review of all verdict parameter handling within the netfilter subsystem and proper validation of input values before they are processed. Organizations should ensure their systems are updated with patches that revert the problematic commit and maintain strict enforcement of errno value ranges for DROP operations. Future implementations requiring userspace specification of errno values must properly validate that error codes remain within acceptable negative ranges using functions like NF_DROP_GETERR and ensuring err <= 0 conditions are maintained to prevent similar issues from reoccurring.
The design decision to not use NF_QUEUE in nftables but instead rely on the "nft_queue" expression indicates a deliberate architectural choice, yet this vulnerability shows how even indirect code paths can introduce security risks. The reverted commit likely introduced this flaw as part of broader changes that didn't properly account for all possible code execution paths within the netfilter framework, highlighting the importance of comprehensive testing and validation when modifying kernel networking components. This vulnerability underscores the critical need for maintaining strict parameter validation in kernel space where incorrect handling can lead to complete system compromise rather than just application-level issues.