Re: [PATCH net-next 0/4] more virtio-net csum hardening

On Tue, Oct 13, 2026 at 2:36 PM Michael S. Tsirkin [off-list ref] wrote:

On Tue, Oct 13, 2026 at 02:29:53PM -0600, Willem de Bruijn wrote:

quoted

On Tue, Oct 13, 2026 at 12:41 PM Michael S. Tsirkin [off-list ref] wrote:

quoted

On Tue, Oct 13, 2026 at 08:41:19AM -0600, Willem de Bruijn wrote:

quoted

On Tue, Oct 13, 2026 at 4:58 AM Michael S. Tsirkin [off-list ref] wrote:

quoted

Allowing untrusted hardware to specify csum start/offset for
CHECKSUM_PARTIAL was not a good idea, because, if it edits the packet
outside the actual checksum, and depending on the setup, the networking
stack could be looking at the packet both before and after the edit, and
seeing different results.

Previously, commit 6785011f8b16 ("ipv4: validate checksum_start before
completing checksum") validated all known instances where this
causes the most grief, but the real fix is to make sure
that either only actual checksum fields are ever edited,
or the checksum is completed before the net stack looks at it,
so it is always consistent.

+1 on the general approach of performing the checksum offload at
input, unless the input can easily be validated to be one of a few
common protocols. That greatly reduces the risk vs my previous attempt
at trying to drop.

Since we do not know the full extent of grief, I think this too should
go to net and stable.

I think it needs a bit more testing to be frank, I do not see it
wait months out of the tree. So if this lands in next before the
merge window, we are good I think. If we miss that I will target net.

quoted

That would mean initially a single patch that
touches as few files as possible. The helper function in
include/linux/ip.h and conversion of existing open coded parsers to
use that can follow up later in net-next.

I don't see the value to be frank.
What moving code between files accomplishes, I donnu.
Squashing things surely makes review harder?
Does your backporting system really struggle with trivial
dependencies like this?

I can drop patch 2 and will if I am targeting net.

Good. This is not about "my" backporting, but upstream stable.
Refactor patches do not belong there.

Since patch 3 might have to be backported in the future if a serious
abuse surfaces, even if you now land it in net-next, it is better to
not depend on other patches.

Right. While this is targeting next, I will reorder it last in series so
it's obvious for people it can be dropped.

Thanks a lot for the review!

Of course. Thanks for the fixes!

I would open-code ip4_parse directly in "net: resolve uncommon partial
checksums at ingress". It's not a lot of code. Then that patch stands
on its own.

And then optionally squash patches 1 and 2 and place them at the end
of this series as one dedup patch, or send that separately later.
Personally I would drop that entirely and leave the existing code as
is. But either way.

quoted

quoted

quoted

quoted

This basically does this: checksum at ingress, except in a narrow list
of specified known good cases.

Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")

Michael S. Tsirkin (4):
  net: add ip4_parse()
  net: use ip4_parse() in receive validation
  net: resolve uncommon partial checksums at ingress
  net: account for ingress-resolved virtio net hdr state