CVE-2026-90145: hinic3: Fix skb linearization mismatch and drop skb when skb_checksum_help() failed
In the Linux kernel, the following vulnerability has been resolved:
hinic3: Fix skb linearization mismatch and drop skb when skbchecksumhelp() failed
Previously, hinic3sendoneskb() cached the skb fragment count before calling hinic3txoffload(). If hinic3txcsum() falls back to skbchecksumhelp() for unsupported tunnel packets, the skb may be linearized. Continuing to build the TX descriptor with the stale fragment count leads to a descriptor mismatch, which can trigger out-of-bounds DMA reads or IOMMU faults.
Furthermore, the old code ignored the return value of skbchecksumhelp(), transmitting corrupted packets with incomplete checksums upon failure.
Fix this by: 1. Moving the hinic3txoffload() call before calculating 'numsge' to ensure the correct fragment count is used if the SKB is linearized. 2. Propagating skbchecksumhelp() errors and returning HINIC3TXOFFLOADINVALID to properly drop the skb.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In hinic3_tx_csum()/hinic3_tx_offload() and the TX descriptor build path: propagate skb_checksum_help() errors; if skb_checksum_help() fails for unsupported tunnel packets, drop the skb instead of transmitting corrupted packets, and ensure the correct fragment count is used after linearizing the skb (fix mismatch that can trigger out-of-bounds DMA reads or IOMMU faults).
HINIC3 network driver TX descriptor/SKB linearization and checksum handling = drop skb when skb_checksum_help() fails; ensure correct fragment count after linearization
Event History
Frequently Asked Questions
Which packets can reach the affected path?
The issue is reached when hinic3 transmit checksum handling falls back to skb_checksum_help() for unsupported tunnel packets. That fallback can linearize the skb after the driver has cached its fragment count.
What are the observable consequences of the stale descriptor state?
A transmit descriptor built with the stale fragment count can mismatch the linearized skb, potentially causing out-of-bounds DMA reads or IOMMU faults. If skb_checksum_help() fails, the prior behavior could also transmit a packet with an incomplete checksum.