Josef Bacik says: ==================== net: skbuff: replace most BUG_ON()s with error returns I'm going through and reducing BUG_ON() usage in areas that have created the most problems for us. 89 commits in the tree quote "kernel BUG at net/core/skbuff.c", 31 of them since 2024, and some of those could be triggered from inside a user namespace. The first patch is a fix: skb_copy_and_csum_bits() leaves stale bytes in a buffer headed for the wire when it hits unreadable frags. The BUG_ON() conversion of the same function needs the same handling, so it's here rather than sent separately. The rest of the series converts 17 of the 19 BUG_ON()s in skbuff.c. Each one becomes if (WARN_ON_ONCE(cond)) <error path>; where the error path is a failure return the function already has and its callers already handle: -EINVAL from pskb_expand_head() and skb_segment(), NULL from skb_copy(), 0 from skb_shift(), and so on. Each patch says what its error path is and why it's safe. Anybody who wants the old behaviour, syzbot included, gets it with panic_on_warn. A few don't have an obvious error return: - skb_copy_and_csum_bits() zeroes the part of the caller's buffer it couldn't fill instead of leaving stale bytes in it. - skb_copy_and_csum_dev() copies the frame without a checksum. It also now catches a csum_start before the head and a csum_offset past the end of the frame, which the BUG_ON() missed. - skb_shift()'s second check ran after the shift had been committed. It moves up to just before the commit, where nothing has changed yet, and returns 0 there. Two BUG_ON()s are left on purpose. __pskb_pull_tail() and skb_pull_rcsum() have callers that can't otherwise fail, so they don't check the return. Some of them would carry on and BUG() somewhere else, or push back a pull that never happened. Those need their callers fixed first and will come as separate series. skb_over_panic() and skb_under_panic() keep their BUG() as well; that's overflow hardening and should stay fatal. skbuff.o text on x86_64 defconfig grows by 114 bytes. The fast path takes the same branch it does today; the extra bytes are the error paths that BUG() used to replace. Testing: x86_64 defconfig with CONFIG_WERROR boots, and every patch builds net/core/skbuff.o on its own with allmodconfig, W=1 and CONFIG_DEBUG_NET. A test module drives 12 of the 17 converted BUG_ON()s with a bad argument or a malformed skb, skb_shift() through a test-only export. Each one warns once and returns its documented error, and the skbs are left alone. The same module covers the unreadable-frags fix. test_bpf's skb_segment tests pass. The other five were only reviewed: skb_crc32c() isn't built in defconfig, and the four skb_segment() layout checks need a crafted frag_list. ==================== Link: https://patch.msgid.link/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>