linux-kernel - Code paths setting gso

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sat, 13 Mar 2010 06:22:57 -0500
From:	William Allen Simpson <william.allen.simpson@...il.com>
To:	Linux Kernel Developers <linux-kernel@...r.kernel.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	Dan Carpenter <error27@...il.com>,
	David Miller <davem@...emloft.net>,
	Simon Horman <horms@...ge.net.au>
Subject: Code paths setting gso_size

This is a new thread dedicated to a specific topic, spawned by an
earlier discussion.  I've CC'd only those that participated recently.

I've written:
# In this particular instance, I suggest that you take a look at all the
# places that gso_size is set, and cross index with all the code paths that
# place these TCP headers onto the txq without a check of doff -- as I did!
#
# I'll specifically mention the tun and virtio_net devices, but I'm also
# particularly concerned with af_packet.c and skbuff.c -- and the general
# problem with inet_lro.c, too.
#
# Amazingly enough, folks sometimes use Linux for routers....
#

Eric (and David) have written:
# Only *locally* generated trafic by linux kernel can enter this path.
#

So, let us begin with the tun device, and work our way through the others.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/