Linux skbuff core turns crash BUG_ONs into recoverable warnings

Josef Bacik has posted a nine-part net-next series that converts most of the remaining BUG_ON() checks in the kernel's central socket buffer (skbuff) code into WARN_ON_ONCE() plus a failure return. The goal is to stop malformed or buggy packet paths from taking down the whole machine.

Those assertions have been a recurring source of production panics. Bacik counts 89 tree commits that quote "kernel BUG at net/core/skbuff.c", 31 of them since 2024, and notes that some could be hit from inside a user namespace. Recent examples include bad GSO layouts reaching segmentation, negative headroom handed to expand helpers, and ICMP paths that asked copy routines for more bytes than the skb held. Each time the old code chose a fatal BUG rather than a drop.

Seventeen of the nineteen BUG_ON sites in the file now warn once and take an error path callers already handle: -EINVAL from expand and segment helpers, NULL from copy routines, 0 from shift, and similar. Operators who still want an immediate stop, including syzbot, retain that behaviour with panic_on_warn. The hot path keeps the same branch it has today; the extra text is only the recovery side, about 114 bytes on a typical x86_64 defconfig.

One accompanying fix closes a quiet data leak. When copy-and-checksum hits unreadable fragments it used to return early and leave the rest of the caller's buffer untouched. Those buffers are often about to go on the wire (ICMP error quotes, driver TX bounce space), so leftover memory could be transmitted. The change zeroes only the unfilled tail for a positive length, so the checksum is still wrong and the packet is dropped, but stale contents are not sent. Related device copy logic also hardens checks around checksum start and offset, falling back to an unchecksummed copy or a zeroed buffer instead of trusting bad geometry.

Two BUG_ON sites stay for now. Pull helpers have callers that ignore failure and would mis-behave or crash elsewhere if the assertion simply returned, so those need caller fixes in follow-up work. The dedicated over- and under-size panic helpers remain fatal as overflow hardening.

The practical effect is that a bad skb is more likely to be discarded with a one-time warning than to panic a host, which matters anywhere untrusted or namespaced workloads can shape traffic that reaches these paths.