In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head()
Why It Matters
Analysis dossierWhy It Matters
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run. Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it. To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.
High Severity / Review
Unknown
Unknown
Risk basis: SOC ecosystem technology relevance; CRITICAL severity; Critical CVSS without confirmed KEV exploitation
Affected Products & Remediation
0 source-backed productsVendor or catalog guidance (source)
Not provided by source
Known exploitation (source facts)
Only what a source states. Unknown means no source has said either way; it is not "not exploited".
- CISA KEV
- Unknown
- Exploited (source statement)
- Unknown
- Publicly disclosed (source)
- Unknown
Suggested hunting (rule-based inference)
SecOps Signal recommendation (rule-based inference). These steps are hunting hypotheses from the vulnerability class; they do not state or imply that exploitation occurred here or anywhere.
Matched network-unauthenticated (CVSS AV:N, CVSS PR:N, CVSS UI:N)
Exposure
- Identify devices reporting this CVE and note which expose the affected service to untrusted networks.Telemetry: DeviceTvmSoftwareVulnerabilities · A network-reachable, no-privilege vector makes internet-facing instances the first exposure question. · Rule network-unauthenticated
Exploitation evidence
- Review inbound connections to the affected service from unexpected sources since the advisory date.Telemetry: DeviceNetworkEvents · Hunting hypothesis from the CVSS vector; it does not show that exploitation occurred. · Rule network-unauthenticated
Response
- Confirm the source-stated update is installed and the CVE is no longer reported.Telemetry: DeviceTvmSoftwareVulnerabilities · A follow-up inventory check verifies remediation. · Rule network-unauthenticated
CISA KEV Record
CISA KEV status was not determined for this record.
Change History & Source Data
— No recorded material change
- CNA / source
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- Record status · verification
- UPDATED · NVD API
- CPE
- Unknown
Evidence & Provenance
— No published hunting query names this record. Browse community and library queries instead.
Correlated briefings
— No published briefing references this CVE