CVE-2022-48748: net: bridge: vlan: fix memory leak in __allowed_ingress
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: vlan: fix memory leak in __allowed_ingress
When using per-vlan state, if vlan snooping and stats are disabled,
untagged or priority-tagged ingress frame will go to check pvid state.
If the port state is forwarding and the pvid state is not
learning/forwarding, untagged or priority-tagged frame will be dropped
but skb memory is not freed.
Should free skb when __allowed_ingress returns false.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can leak packet memory in specific bridge VLAN handling. An attacker able to send suitable traffic to an affected Linux bridge could consume memory and degrade or deny service. The available sources describe availability impact only, not data theft or code execution.
Executive priority
Prioritize remediation for Linux-based network infrastructure that bridges VLAN traffic. The main business risk is service disruption from memory exhaustion, not confidentiality loss. Patch through normal emergency or accelerated infrastructure maintenance depending on exposure.
Technical view
The bug is in Linux bridge VLAN ingress handling in __allowed_ingress. With per-VLAN state, VLAN snooping and stats disabled, certain untagged or priority-tagged frames are dropped without freeing the skb when PVID state blocks forwarding or learning, causing a memory leak.
Likely exposure
Exposure is most relevant to Linux systems using kernel bridge VLAN features, especially network appliances, virtualization hosts, or servers bridging VLAN traffic. Systems not using Linux bridge VLAN ingress paths are less likely exposed. The bundle does not identify distributions or downstream package names.
Exploitation context
The CVSS vector indicates network, low-complexity, unauthenticated availability impact. The bundle states KEV is false and provides no cited evidence of active exploitation. Treat exploitation status as unconfirmed, not actively exploited.
Researcher notes
Evidence is limited to the CVE description and Linux stable commit references. The affected version data in the bundle is sparse, so downstream kernel package validation should rely on vendor advisories and commit backports rather than version strings alone.
Mitigation direction
Check vendor kernel advisories for your distribution or appliance.
Update to a kernel containing one of the referenced stable fixes.
Prioritize internet- or untrusted-network-facing Linux bridges using VLAN filtering.
Temporarily reduce exposure of affected bridge VLAN paths where patching is delayed.
Monitor memory pressure and packet-drop symptoms on suspected bridge hosts.
Validation and detection
Inventory Linux systems using bridge VLAN or related network appliance functions.
Map running kernel versions against vendor advisories and referenced stable commits.
Confirm whether VLAN snooping, stats, per-VLAN state, and PVID behavior match exposure conditions.
Review operational monitoring for unexplained memory growth on bridge hosts.
Verify patched kernels include the relevant stable commit for their branch.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-400: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-400 · source CWE mapping
Uncontrolled Resource Consumption
Uncontrolled Resource Consumption represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.