*skb_sec_path(struct sk_buff *skb)
* Keeps track of level of encapsulation of network headers.
*/
struct skb_gso_cb {
+ char pad[32]; /* inet_skb_parm lives here */
int mac_offset;
int encap_level;
__u16 csum_start;
And debug which prevents kernel crash too.
From: Cong Wang <hidden> Date: 2016-01-06 19:59:27
On Wed, Jan 6, 2016 at 11:15 AM, Konstantin Khlebnikov [off-list ref] wrote:
Looks like this happens because ip_options_fragment() relies on
correct ip options length in ip control block in skb. But in
ip_finish_output_gso() control block in segments is reused by
skb_gso_segment(). following ip_fragment() sees some garbage.
In my case there was no ip options but length becomes non-zero and
ip_options_fragment() picked some bytes from payload and decides to
fill huge range with IPOPT_NOOP (1). One of that ones flipped nr_frags
in skb_shared_info at the end of data =)
Hmm, it looks like SKB_GSO_CB should be cleared after skb_gso_segment()
since all the gso information should be saved in shared_info after it finishes.
Does a memset(0) on SKB_GSO_CB after skb_gso_segment() work as well?
From: Konstantin Khlebnikov <hidden> Date: 2016-01-06 20:11:46
On Wed, Jan 6, 2016 at 10:59 PM, Cong Wang [off-list ref] wrote:
On Wed, Jan 6, 2016 at 11:15 AM, Konstantin Khlebnikov [off-list ref] wrote:
quoted
Looks like this happens because ip_options_fragment() relies on
correct ip options length in ip control block in skb. But in
ip_finish_output_gso() control block in segments is reused by
skb_gso_segment(). following ip_fragment() sees some garbage.
In my case there was no ip options but length becomes non-zero and
ip_options_fragment() picked some bytes from payload and decides to
fill huge range with IPOPT_NOOP (1). One of that ones flipped nr_frags
in skb_shared_info at the end of data =)
Hmm, it looks like SKB_GSO_CB should be cleared after skb_gso_segment()
since all the gso information should be saved in shared_info after it finishes.
Does a memset(0) on SKB_GSO_CB after skb_gso_segment() work as well?
This will break present logic around ip_options_fragment() - it clears
options from
second and following fragments. With zeroed cb it will do nothing.
ip_options_fragment() can get required information directly from ip header but
it also resets fields in IPCB -- probably it should stay valid here
and somebody else will use it later.
From: Thadeu Lima de Souza Cascardo <hidden> Date: 2016-01-06 21:05:43
On Wed, Jan 06, 2016 at 11:11:41PM +0300, Konstantin Khlebnikov wrote:
On Wed, Jan 6, 2016 at 10:59 PM, Cong Wang [off-list ref] wrote:
quoted
On Wed, Jan 6, 2016 at 11:15 AM, Konstantin Khlebnikov [off-list ref] wrote:
quoted
Looks like this happens because ip_options_fragment() relies on
correct ip options length in ip control block in skb. But in
ip_finish_output_gso() control block in segments is reused by
skb_gso_segment(). following ip_fragment() sees some garbage.
In my case there was no ip options but length becomes non-zero and
ip_options_fragment() picked some bytes from payload and decides to
fill huge range with IPOPT_NOOP (1). One of that ones flipped nr_frags
in skb_shared_info at the end of data =)
Hmm, it looks like SKB_GSO_CB should be cleared after skb_gso_segment()
since all the gso information should be saved in shared_info after it finishes.
Does a memset(0) on SKB_GSO_CB after skb_gso_segment() work as well?
This will break present logic around ip_options_fragment() - it clears
options from
second and following fragments. With zeroed cb it will do nothing.
ip_options_fragment() can get required information directly from ip header but
it also resets fields in IPCB -- probably it should stay valid here
and somebody else will use it later.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I have hit this as well, this fixes it for me on an older kernel. Can you try it
on latest kernel?
@@ -216,6 +216,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)netdev_features_tfeatures;structsk_buff*segs;intret=0;+structinet_skb_parmipcb;if(skb_gso_network_seglen(skb)<=ip_skb_dst_mtu(skb))returnip_finish_output2(skb);
@@ -227,6 +228,10 @@ static int ip_finish_output_gso(struct sk_buff *skb)*2)skbarrivedviavirtio-net,wethusgetTSO/GSOskbsdirectly*fromhostnetworkstack.*/+/* We need to save IPCB here because skb_gso_segment will use+*SKB_GSO_CB.+*/+ipcb=*IPCB(skb);features=netif_skb_features(skb);segs=skb_gso_segment(skb,features&~NETIF_F_GSO_MASK);if(IS_ERR_OR_NULL(segs)){
@@ -241,6 +246,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)interr;segs->next=NULL;+*IPCB(segs)=ipcb;err=ip_fragment(segs,ip_finish_output2);if(err&&ret==0)
Thadeu Lima de Souza Cascardo [off-list ref] wrote:
On Wed, Jan 06, 2016 at 11:11:41PM +0300, Konstantin Khlebnikov wrote:
quoted
On Wed, Jan 6, 2016 at 10:59 PM, Cong Wang [off-list ref] wrote:
quoted
On Wed, Jan 6, 2016 at 11:15 AM, Konstantin Khlebnikov [off-list ref] wrote:
quoted
Looks like this happens because ip_options_fragment() relies on
correct ip options length in ip control block in skb. But in
ip_finish_output_gso() control block in segments is reused by
skb_gso_segment(). following ip_fragment() sees some garbage.
In my case there was no ip options but length becomes non-zero and
ip_options_fragment() picked some bytes from payload and decides to
fill huge range with IPOPT_NOOP (1). One of that ones flipped nr_frags
in skb_shared_info at the end of data =)
Hmm, it looks like SKB_GSO_CB should be cleared after skb_gso_segment()
since all the gso information should be saved in shared_info after it finishes.
Does a memset(0) on SKB_GSO_CB after skb_gso_segment() work as well?
This will break present logic around ip_options_fragment() - it clears
options from
second and following fragments. With zeroed cb it will do nothing.
ip_options_fragment() can get required information directly from ip header but
it also resets fields in IPCB -- probably it should stay valid here
and somebody else will use it later.
[..]
I have hit this as well, this fixes it for me on an older kernel. Can you try it
on latest kernel?
@@ -216,6 +216,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)netdev_features_tfeatures;structsk_buff*segs;intret=0;+structinet_skb_parmipcb;if(skb_gso_network_seglen(skb)<=ip_skb_dst_mtu(skb))returnip_finish_output2(skb);
@@ -227,6 +228,10 @@ static int ip_finish_output_gso(struct sk_buff *skb)*2)skbarrivedviavirtio-net,wethusgetTSO/GSOskbsdirectly*fromhostnetworkstack.*/+/* We need to save IPCB here because skb_gso_segment will use+*SKB_GSO_CB.+*/+ipcb=*IPCB(skb);features=netif_skb_features(skb);segs=skb_gso_segment(skb,features&~NETIF_F_GSO_MASK);if(IS_ERR_OR_NULL(segs)){
@@ -241,6 +246,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)interr;segs->next=NULL;+*IPCB(segs)=ipcb;err=ip_fragment(segs,ip_finish_output2);if(err&&ret==0)
I'm worried that this doesn't solve all cases. f.e. xfrm may also
call skb_gso_segment(), and it will call into ipv4/ipv6 netfilter
postrouting + ipv4 output functions...
nfqnl_enqueue_packet() is also affected.
@@ -216,6 +216,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)netdev_features_tfeatures;structsk_buff*segs;intret=0;+structinet_skb_parmipcb;if(skb_gso_network_seglen(skb)<=ip_skb_dst_mtu(skb))returnip_finish_output2(skb);
@@ -227,6 +228,10 @@ static int ip_finish_output_gso(struct sk_buff *skb)*2)skbarrivedviavirtio-net,wethusgetTSO/GSOskbsdirectly*fromhostnetworkstack.*/+/* We need to save IPCB here because skb_gso_segment will use+*SKB_GSO_CB.+*/+ipcb=*IPCB(skb);features=netif_skb_features(skb);segs=skb_gso_segment(skb,features&~NETIF_F_GSO_MASK);if(IS_ERR_OR_NULL(segs)){
@@ -241,6 +246,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)interr;segs->next=NULL;+*IPCB(segs)=ipcb;err=ip_fragment(segs,ip_finish_output2);if(err&&ret==0)
I'm worried that this doesn't solve all cases. f.e. xfrm may also
call skb_gso_segment(), and it will call into ipv4/ipv6 netfilter
postrouting + ipv4 output functions...
nfqnl_enqueue_packet() is also affected.
... but it seems that those three are the only affected callers
of skb_gso_segment (tbf is ok since skb isn't owned by anyone,
ovs does save/restore already).
I think this patch is the right way, we just need similar
save/restore in nfqnl_enqueue_packet and xfrm_output_gso().
The latter two can be used by either ipv4 or ipv6 so it might
be preferable to just save/restore sizeof(struct skb_gso_cb);
or a union of inet_skb_parm+inet6_skb_parm.
Cascardo, can you cook a patch?
Thanks!
@@ -216,6 +216,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)netdev_features_tfeatures;structsk_buff*segs;intret=0;+structinet_skb_parmipcb;if(skb_gso_network_seglen(skb)<=ip_skb_dst_mtu(skb))returnip_finish_output2(skb);
@@ -227,6 +228,10 @@ static int ip_finish_output_gso(struct sk_buff *skb)*2)skbarrivedviavirtio-net,wethusgetTSO/GSOskbsdirectly*fromhostnetworkstack.*/+/* We need to save IPCB here because skb_gso_segment will use+*SKB_GSO_CB.+*/+ipcb=*IPCB(skb);features=netif_skb_features(skb);segs=skb_gso_segment(skb,features&~NETIF_F_GSO_MASK);if(IS_ERR_OR_NULL(segs)){
@@ -241,6 +246,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)interr;segs->next=NULL;+*IPCB(segs)=ipcb;err=ip_fragment(segs,ip_finish_output2);if(err&&ret==0)
I'm worried that this doesn't solve all cases. f.e. xfrm may also
call skb_gso_segment(), and it will call into ipv4/ipv6 netfilter
postrouting + ipv4 output functions...
nfqnl_enqueue_packet() is also affected.
... but it seems that those three are the only affected callers
of skb_gso_segment (tbf is ok since skb isn't owned by anyone,
ovs does save/restore already).
I think this patch is the right way, we just need similar
save/restore in nfqnl_enqueue_packet and xfrm_output_gso().
Which CB could be here? at this point skb isn't owned by netlink yet.
The latter two can be used by either ipv4 or ipv6 so it might
be preferable to just save/restore sizeof(struct skb_gso_cb);
or a union of inet_skb_parm+inet6_skb_parm.
Or just shift GSO CB and add couple checks like
BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb)));
@@ -216,6 +216,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)netdev_features_tfeatures;structsk_buff*segs;intret=0;+structinet_skb_parmipcb;if(skb_gso_network_seglen(skb)<=ip_skb_dst_mtu(skb))returnip_finish_output2(skb);
@@ -227,6 +228,10 @@ static int ip_finish_output_gso(struct sk_buff *skb)*2)skbarrivedviavirtio-net,wethusgetTSO/GSOskbsdirectly*fromhostnetworkstack.*/+/* We need to save IPCB here because skb_gso_segment will use+*SKB_GSO_CB.+*/+ipcb=*IPCB(skb);features=netif_skb_features(skb);segs=skb_gso_segment(skb,features&~NETIF_F_GSO_MASK);if(IS_ERR_OR_NULL(segs)){
@@ -241,6 +246,7 @@ static int ip_finish_output_gso(struct sk_buff *skb)interr;segs->next=NULL;+*IPCB(segs)=ipcb;err=ip_fragment(segs,ip_finish_output2);if(err&&ret==0)
I'm worried that this doesn't solve all cases. f.e. xfrm may also
call skb_gso_segment(), and it will call into ipv4/ipv6 netfilter
postrouting + ipv4 output functions...
nfqnl_enqueue_packet() is also affected.
... but it seems that those three are the only affected callers
of skb_gso_segment (tbf is ok since skb isn't owned by anyone,
ovs does save/restore already).
I think this patch is the right way, we just need similar
save/restore in nfqnl_enqueue_packet and xfrm_output_gso().
Which CB could be here? at this point skb isn't owned by netlink yet.
quoted
The latter two can be used by either ipv4 or ipv6 so it might
be preferable to just save/restore sizeof(struct skb_gso_cb);
or a union of inet_skb_parm+inet6_skb_parm.
Or just shift GSO CB and add couple checks like
BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb)));
Somethin like this (in attachment)
Also I've found strange thing: reason of expanding skb->cb from 40 to
48 bypes in 2006
3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
not fit. But it's is only 24 bytes. Does some arches add pad after
each _u16 field?
From: Eric Dumazet <edumazet@google.com> Date: 2016-01-07 11:59:09
On Thu, Jan 7, 2016 at 6:38 AM, Konstantin Khlebnikov [off-list ref] wrote:
Also I've found strange thing: reason of expanding skb->cb from 40 to
48 bypes in 2006
3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
not fit. But it's is only 24 bytes. Does some arches add pad after
each _u16 field?
"struct inet6_skb_parm" is part of struct tcp_skb_cb
This is why Patrick had to increase skb->cb[]
On Thu, Jan 7, 2016 at 2:49 AM, Florian Westphal [off-list ref] wrote:
quoted
... but it seems that those three are the only affected callers
of skb_gso_segment (tbf is ok since skb isn't owned by anyone,
ovs does save/restore already).
I think this patch is the right way, we just need similar
save/restore in nfqnl_enqueue_packet and xfrm_output_gso().
Which CB could be here? at this point skb isn't owned by netlink yet.
inet(6)_skb_parm, nfqnl_enqueue_packet is called via netfilter hooks, skb
is owned by ipv4 or ipv6 stack.
quoted
The latter two can be used by either ipv4 or ipv6 so it might
be preferable to just save/restore sizeof(struct skb_gso_cb);
or a union of inet_skb_parm+inet6_skb_parm.
Or just shift GSO CB and add couple checks like
BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb)));
From: Konstantin Khlebnikov <hidden> Date: 2016-01-07 12:04:20
On Thu, Jan 7, 2016 at 2:59 PM, Eric Dumazet [off-list ref] wrote:
On Thu, Jan 7, 2016 at 6:38 AM, Konstantin Khlebnikov [off-list ref] wrote:
quoted
Also I've found strange thing: reason of expanding skb->cb from 40 to
48 bypes in 2006
3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
not fit. But it's is only 24 bytes. Does some arches add pad after
each _u16 field?
"struct inet6_skb_parm" is part of struct tcp_skb_cb
This is why Patrick had to increase skb->cb[]
Whoa. Funny. TCP moves that chunk back and forward instead of just
putting it at the first place in struct.
From: Eric Dumazet <edumazet@google.com> Date: 2016-01-07 12:54:14
On Thu, Jan 7, 2016 at 7:04 AM, Konstantin Khlebnikov [off-list ref] wrote:
On Thu, Jan 7, 2016 at 2:59 PM, Eric Dumazet [off-list ref] wrote:
quoted
On Thu, Jan 7, 2016 at 6:38 AM, Konstantin Khlebnikov [off-list ref] wrote:
quoted
Also I've found strange thing: reason of expanding skb->cb from 40 to
48 bypes in 2006
3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
not fit. But it's is only 24 bytes. Does some arches add pad after
each _u16 field?
"struct inet6_skb_parm" is part of struct tcp_skb_cb
This is why Patrick had to increase skb->cb[]
Whoa. Funny. TCP moves that chunk back and forward instead of just
putting it at the first place in struct.
You probably want to look at git history to find out why it is done this way.
TCP performance is critical for some of us, and doing such trick avoid
one cache miss per skb in some critical list traversals.
From: Thadeu Lima de Souza Cascardo <hidden> Date: 2016-01-07 18:43:15
skb_gso_segment uses skb->cb, which may be owned by the caller. This may
cause IPCB(skb)->opt.optlen to be overwritten, which will make
ip_fragment overwrite skb data and possibly skb_shinfo with IPOPT_NOOP,
thus causing a crash.
This patch saves skb->cb before calling skb_gso_segment for those users
that have anything to save, then restore it for each GSO segment.
Signed-off-by: Thadeu Lima de Souza Cascardo <redacted>
---
net/ipv4/ip_output.c | 3 +++
net/netfilter/nfnetlink_queue.c | 7 +++++++
net/xfrm/xfrm_output.c | 6 ++++++
3 files changed, 16 insertions(+)
@@ -226,6 +226,7 @@ static int ip_finish_output_gso(struct net *net, struct sock *sk,netdev_features_tfeatures;structsk_buff*segs;intret=0;+structinet_skb_parmipcb;/* common case: locally created skb or seglen is <= mtu */if(((IPCB(skb)->flags&IPSKB_FORWARDED)==0)||
@@ -239,6 +240,7 @@ static int ip_finish_output_gso(struct net *net, struct sock *sk,*2)skbarrivedviavirtio-net,wethusgetTSO/GSOskbsdirectly*fromhostnetworkstack.*/+ipcb=*IPCB(skb);features=netif_skb_features(skb);segs=skb_gso_segment(skb,features&~NETIF_F_GSO_MASK);if(IS_ERR_OR_NULL(segs)){
@@ -253,6 +255,7 @@ static int ip_finish_output_gso(struct net *net, struct sock *sk,interr;segs->next=NULL;+*IPCB(segs)=ipcb;err=ip_fragment(net,sk,segs,mtu,ip_finish_output2);if(err&&ret==0)
@@ -678,6 +679,10 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)interr=-ENOBUFS;structnet*net=entry->state.net;structnfnl_queue_net*q=nfnl_queue_pernet(net);+union{+structinet_skb_parmh4;+structinet6_skb_parmh6;+}header;/* rcu_read_lock()ed by nf_hook_slow() */queue=instance_lookup(q,queuenum);
@@ -702,6 +707,7 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)return__nfqnl_enqueue_packet(net,queue,entry);nf_bridge_adjust_skb_data(skb);+memcpy(&header,skb->cb,sizeof(header));segs=skb_gso_segment(skb,0);/* Does not use PTR_ERR to limit the number of error codes that can be*returnedbynf_queue.Forinstance,callersrelyon-ESRCHto
@@ -713,6 +719,7 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)err=0;do{structsk_buff*nskb=segs->next;+memcpy(skb->cb,&header,sizeof(header));if(err==0)err=__nfqnl_enqueue_packet_gso(net,queue,segs,entry);
Thadeu Lima de Souza Cascardo [off-list ref] wrote:
skb_gso_segment uses skb->cb, which may be owned by the caller. This may
cause IPCB(skb)->opt.optlen to be overwritten, which will make
ip_fragment overwrite skb data and possibly skb_shinfo with IPOPT_NOOP,
thus causing a crash.
This patch saves skb->cb before calling skb_gso_segment for those users
that have anything to save, then restore it for each GSO segment.
@@ -678,6 +679,10 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)interr=-ENOBUFS;structnet*net=entry->state.net;structnfnl_queue_net*q=nfnl_queue_pernet(net);+union{+structinet_skb_parmh4;+structinet6_skb_parmh6;+}header;/* rcu_read_lock()ed by nf_hook_slow() */queue=instance_lookup(q,queuenum);
@@ -702,6 +707,7 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)return__nfqnl_enqueue_packet(net,queue,entry);nf_bridge_adjust_skb_data(skb);+memcpy(&header,skb->cb,sizeof(header));segs=skb_gso_segment(skb,0);/* Does not use PTR_ERR to limit the number of error codes that can be*returnedbynf_queue.Forinstance,callersrelyon-ESRCHto
@@ -713,6 +719,7 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)err=0;do{structsk_buff*nskb=segs->next;+memcpy(skb->cb,&header,sizeof(header));
I think this should be 'segs->cb'.
Other than that, this looks good to me.
From: Konstantin Khlebnikov <hidden> Date: 2016-01-07 19:35:30
On Thu, Jan 7, 2016 at 3:54 PM, Eric Dumazet [off-list ref] wrote:
On Thu, Jan 7, 2016 at 7:04 AM, Konstantin Khlebnikov [off-list ref] wrote:
quoted
On Thu, Jan 7, 2016 at 2:59 PM, Eric Dumazet [off-list ref] wrote:
quoted
On Thu, Jan 7, 2016 at 6:38 AM, Konstantin Khlebnikov [off-list ref] wrote:
quoted
Also I've found strange thing: reason of expanding skb->cb from 40 to
48 bypes in 2006
3e3850e989c5d2eb1aab6f0fd9257759f0f4cbc6 was that struct inet6_skb_parm does
not fit. But it's is only 24 bytes. Does some arches add pad after
each _u16 field?
"struct inet6_skb_parm" is part of struct tcp_skb_cb
This is why Patrick had to increase skb->cb[]
Whoa. Funny. TCP moves that chunk back and forward instead of just
putting it at the first place in struct.
You probably want to look at git history to find out why it is done this way.
TCP performance is critical for some of us, and doing such trick avoid
one cache miss per skb in some critical list traversals.
Right. This way tcp stuff perfectly fits into leftovers of first cache line.
Then probably it's better to put ipv4/ipv6 cb into second line from
the beginning.
From: Eric Dumazet <edumazet@google.com> Date: 2016-01-07 19:47:10
On Thu, Jan 7, 2016 at 2:35 PM, Konstantin Khlebnikov [off-list ref] wrote:
On Thu, Jan 7, 2016 at 3:54 PM, Eric Dumazet [off-list ref] wrote:
want to look at git history to find out why it is done this way.
quoted
TCP performance is critical for some of us, and doing such trick avoid
one cache miss per skb in some critical list traversals.
Right. This way tcp stuff perfectly fits into leftovers of first cache line.
Then probably it's better to put ipv4/ipv6 cb into second line from
the beginning.
Then IP forwarding might be slower.
Look, each layer (TCP , IP, ....) can organize its skb->cb[] as it wants.
Nobody tries to 'make universal room' for IPCB, since only IP layer wants it.
TCP could even find a way in the future to no longer hold a copy of
IPCB in the input skb,
if code is reorganized a bit.
Note that skbs for output path in TCP do not need IPCB at all.
Only when skb leaves TCP and enter IP, skb->cb[] content is scratched.
From: Thadeu Lima de Souza Cascardo <hidden> Date: 2016-01-07 21:16:57
skb_gso_segment uses skb->cb, which may be owned by the caller. This may
cause IPCB(skb)->opt.optlen to be overwritten, which will make
ip_fragment overwrite skb data and possibly skb_shinfo with IPOPT_NOOP,
thus causing a crash.
This patch saves skb->cb before calling skb_gso_segment for those users
that have anything to save, then restore it for each GSO segment.
Signed-off-by: Thadeu Lima de Souza Cascardo <redacted>
---
net/ipv4/ip_output.c | 3 +++
net/netfilter/nfnetlink_queue.c | 7 +++++++
net/xfrm/xfrm_output.c | 6 ++++++
3 files changed, 16 insertions(+)
@@ -226,6 +226,7 @@ static int ip_finish_output_gso(struct net *net, struct sock *sk,netdev_features_tfeatures;structsk_buff*segs;intret=0;+structinet_skb_parmipcb;/* common case: locally created skb or seglen is <= mtu */if(((IPCB(skb)->flags&IPSKB_FORWARDED)==0)||
@@ -239,6 +240,7 @@ static int ip_finish_output_gso(struct net *net, struct sock *sk,*2)skbarrivedviavirtio-net,wethusgetTSO/GSOskbsdirectly*fromhostnetworkstack.*/+ipcb=*IPCB(skb);features=netif_skb_features(skb);segs=skb_gso_segment(skb,features&~NETIF_F_GSO_MASK);if(IS_ERR_OR_NULL(segs)){
@@ -253,6 +255,7 @@ static int ip_finish_output_gso(struct net *net, struct sock *sk,interr;segs->next=NULL;+*IPCB(segs)=ipcb;err=ip_fragment(net,sk,segs,mtu,ip_finish_output2);if(err&&ret==0)
@@ -678,6 +679,10 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)interr=-ENOBUFS;structnet*net=entry->state.net;structnfnl_queue_net*q=nfnl_queue_pernet(net);+union{+structinet_skb_parmh4;+structinet6_skb_parmh6;+}header;/* rcu_read_lock()ed by nf_hook_slow() */queue=instance_lookup(q,queuenum);
@@ -702,6 +707,7 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)return__nfqnl_enqueue_packet(net,queue,entry);nf_bridge_adjust_skb_data(skb);+memcpy(&header,skb->cb,sizeof(header));segs=skb_gso_segment(skb,0);/* Does not use PTR_ERR to limit the number of error codes that can be*returnedbynf_queue.Forinstance,callersrelyon-ESRCHto
@@ -713,6 +719,7 @@ nfqnl_enqueue_packet(struct nf_queue_entry *entry, unsigned int queuenum)err=0;do{structsk_buff*nskb=segs->next;+memcpy(segs->cb,&header,sizeof(header));if(err==0)err=__nfqnl_enqueue_packet_gso(net,queue,segs,entry);