CVE-2026-90114 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: Reject descending VLAN tunnel ranges
A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta.
The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable.
Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL.
This issue was found by a static analysis checker and confirmed by manual source review.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel networking subsystem contains a critical logic flaw within the bridge module related to VLAN tunnel range validation. This vulnerability arises from an improper handling of integer arithmetic when validating descending VLAN identifiers against tunnel IDs. Specifically, the code performs subtraction operations on VLAN and tunnel identifiers without first ensuring that the resulting values are positive or logically consistent with expected ranges. When a user provides a pair of VLAN and tunnel IDs where the starting value is greater than the ending value, creating a descending range, the arithmetic operation yields a negative integer result for the VLAN span. This signed negative integer is then implicitly converted to an unsigned 32-bit integer during comparison with the tunnel ID subtraction result. Due to two's complement representation, this conversion results in a very large positive number that coincidentally matches or exceeds the expected delta of the tunnel IDs, thereby bypassing the intended range span check logic.
The operational impact of this flaw is significant because it allows malformed input to pass initial validation checks without triggering an error condition as intended by the security design. The bridge subsystem relies on a loop structure to process batched notifications associated with these ranges. Because the descending range causes the loop conditions to evaluate incorrectly, the loop performs zero iterations. Crucially, modern kernel code often employs post-loop error checking mechanisms that assume certain variables have been initialized during normal execution flow. In this scenario, since no iterations occur, a specific error variable remains uninitialized. Consequently, when the function returns its status code, it may return garbage data from the stack rather than a defined error code like -EINVAL or success indicator 0. This unpredictability can lead to undefined behavior in higher-level networking stacks that interpret these return values, potentially causing kernel panics, information leaks of kernel memory contents via uninitialized variables, or logic errors in network configuration management tools.
From a vulnerability classification perspective, this issue aligns with CWE-190 Integer Overflow or Wraparound and CWE-457 Use of Uninitialized Variable. The core failure is rooted in the lack of signedness awareness during arithmetic operations involving user-supplied data, which falls under CWE-682 Incorrect Calculation. Furthermore, the resulting undefined behavior due to uninitialized variables represents a classic memory safety issue often associated with CWE-908 Use of Uninitialized Resource. In terms of attack vectors and detection techniques referenced by MITRE ATT&CK, this type of logic error is typically exploited through local privilege escalation or denial-of-service scenarios where an unprivileged user can trigger the malformed input path to destabilize the kernel network stack. It may also be detected via static analysis tools that identify potential uninitialized variable usage in control flow paths with early exits or zero-iteration loops.
The resolution involves enforcing strict validation of VLAN ranges before any arithmetic comparisons are performed. By rejecting descending VLAN ranges explicitly, the code ensures that only valid ascending or single-entry ranges proceed to further processing. This pre-validation step prevents the negative integer conversion issue entirely, ensuring that all subsequent logic operates on predictable and safe values. The fix maintains backward compatibility for legitimate configurations while consistently returning -EINVAL for malformed inputs, thereby eliminating the path that leads to uninitialized variable usage. To mitigate similar risks in other subsystems, developers should enforce explicit signedness checks before arithmetic operations involving user-controlled indices or ranges and ensure all error paths initialize status variables regardless of loop execution counts. Regular static analysis integration into the development pipeline is recommended to catch such logic errors early, as they are often subtle and difficult to detect through manual code review alone without specialized tooling focused on integer safety and variable initialization states.