Michael S. Tsirkin wrote: > On Fri, Oct 23, 2026 at 11:09:17AM -0400, Michael S. Tsirkin wrote: > > > > Okay this seems to be converging.... But sashiko did find some issues I > > thought are best fixed. Specifically I thought of a better way to handle > > short gso in a tunnel - just clear tunnel gso! As a side effect we now > > fix up the checksum for these dodgy packets like we did before, instead > > of a drop. Good. And more false positives that prompted me to write a > > bit more comments. So here goes. > > > > Apologies for reposting so frequently, I know netdev bot will be unhappy > > with that. But Paulos's report made a lot of publicity, there is a lot > > of people looking into this, so I feel there's value in defending > > against all this class of issues sooner rather than later. > > > > The issues were mostly found by code inspection, but all reproduced by > > me in a VM. > > Ugh. I found another wrinkle( Firewalls that shape the payload. > They are currently seem to simply be hoping most traffic is CHECKSUM_PARTIAL > and > only looking at that, and that will break. > > I am not sure what to do yet. Extending the sysctl knob to control what > happens if validation fails: pass/drop/complete - is the best I could > come up with. Or ignore the issue. Or just forget the complete at input hack > and drop if we can't figure it out.
Sounds like such users will just have to disable the sysctl for now: pass. And update their firewall, then reenable the sysctl? Does adding a third drop option help in any way? The sysctl is the safety valve to go back to old behavior.
