On Sat, Oct 24, 2026 at 12:08:55PM -0400, Willem de Bruijn wrote: > 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.
Yes, maybe that's enough. I was just hopeful there's no known broken valid setup, now not only we found it, is is actually unfixable ( Still trying to decide what to do. -- MST
