summaryrefslogtreecommitdiff
path: root/drivers/net/e1000
diff options
context:
space:
mode:
authorDimitris Michailidis <dm@chelsio.com>2009-01-27 09:15:31 +0300
committerDavid S. Miller <davem@davemloft.net>2009-01-27 09:15:31 +0300
commit9fa5fdf291c9b58b1cb8b4bb2a0ee57efa21d635 (patch)
treecfa28bcf674ef224a5ab66b3b8bc4bc1091ccb11 /drivers/net/e1000
parenta7a41acf99d9150b424839b0d7b4f5ad9d211e2d (diff)
downloadlinux-9fa5fdf291c9b58b1cb8b4bb2a0ee57efa21d635.tar.xz
tcp: Fix length tcp_splice_data_recv passes to skb_splice_bits.
tcp_splice_data_recv has two lengths to consider: the len parameter it gets from tcp_read_sock, which specifies the amount of data in the skb, and rd_desc->count, which is the amount of data the splice caller still wants. Currently it passes just the latter to skb_splice_bits, which then splices min(rd_desc->count, skb->len - offset) bytes. Most of the time this is fine, except when the skb contains urgent data. In that case len goes only up to the urgent byte and is less than skb->len - offset. By ignoring len tcp_splice_data_recv may a) splice data tcp_read_sock told it not to, b) return to tcp_read_sock a value > len. Now, tcp_read_sock doesn't handle used > len and leaves the socket in a bad state (both sk_receive_queue and copied_seq are bad at that point) resulting in duplicated data and corruption. Fix by passing min(rd_desc->count, len) to skb_splice_bits. Signed-off-by: Dimitris Michailidis <dm@chelsio.com> Acked-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/e1000')
0 files changed, 0 insertions, 0 deletions