When TEE target mirrors traffic to another interface, sk_buff may
not have enough headroom to be processed correctly.
ip_finish_output2() detect this situation for ipv4 and allocates
new skb with enogh headroom. However ipv6 lacks this logic in
ip_finish_output2 and it leads to skb_under_panic:
skbuff: skb_under_panic: text:ffffffffc0866ad4 len:96 put:24
head:ffff97be85e31800 data:ffff97be85e317f8 tail:0x58 end:0xc0 dev:gre0
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:110!
invalid opcode: 0000 [#1] SMP PTI
CPU: 2 PID: 393 Comm: kworker/2:2 Tainted: G OE 5.13.0 #13
Hardware name: Virtuozzo KVM, BIOS 1.11.0-2.vz7.4 04/01/2014
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:skb_panic+0x48/0x4a
Call Trace:
skb_push.cold.111+0x10/0x10
ipgre_header+0x24/0xf0 [ip_gre]
neigh_connected_output+0xae/0xf0
ip6_finish_output2+0x1a8/0x5a0
ip6_output+0x5c/0x110
nf_dup_ipv6+0x158/0x1000 [nf_dup_ipv6]
tee_tg6+0x2e/0x40 [xt_TEE]
ip6t_do_table+0x294/0x470 [ip6_tables]
nf_hook_slow+0x44/0xc0
nf_hook.constprop.34+0x72/0xe0
ndisc_send_skb+0x20d/0x2e0
ndisc_send_ns+0xd1/0x210
addrconf_dad_work+0x3c8/0x540
process_one_work+0x1d1/0x370
worker_thread+0x30/0x390
kthread+0x116/0x130
ret_from_fork+0x22/0x30
Signed-off-by: Vasily Averin <[email protected]>
---
net/ipv6/ip6_output.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index ff4f9eb..e5af740 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -61,9 +61,24 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
struct dst_entry *dst = skb_dst(skb);
struct net_device *dev = dst->dev;
const struct in6_addr *nexthop;
+ unsigned int hh_len = LL_RESERVED_SPACE(dev);
struct neighbour *neigh;
int ret;
+ /* Be paranoid, rather than too clever. */
+ if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
+ struct sk_buff *skb2;
+
+ skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
+ if (!skb2) {
+ kfree_skb(skb);
+ return -ENOMEM;
+ }
+ if (skb->sk)
+ skb_set_owner_w(skb2, skb->sk);
+ consume_skb(skb);
+ skb = skb2;
+ }
if (ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr)) {
struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
--
1.8.3.1
On Wed, 7 Jul 2021 19:41:44 +0200 Eric Dumazet wrote:
> On 7/7/21 6:42 PM, Jakub Kicinski wrote:
> > On Wed, 7 Jul 2021 08:45:13 -0600 David Ahern wrote:
> >> why not use hh_len here?
> >
> > Is there a reason for the new skb? Why not pskb_expand_head()?
>
>
> pskb_expand_head() might crash, if skb is shared.
>
> We possibly can add a helper, factorizing all this,
> and eventually use pskb_expand_head() if safe.
Is there a strategically placed skb_share_check() somewhere further
down? Otherwise there seems to be a lot of questionable skb_cow*()
calls, also __skb_linearize() and skb_pad() are risky, no?
Or is it that shared skbs are uncommon and syzbot doesn't hit them?
On 7/7/21 8:41 PM, Eric Dumazet wrote:
> On 7/7/21 6:42 PM, Jakub Kicinski wrote:
>> On Wed, 7 Jul 2021 08:45:13 -0600 David Ahern wrote:
>>> On 7/7/21 8:04 AM, Vasily Averin wrote:
>>>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>>>> index ff4f9eb..e5af740 100644
>>>> --- a/net/ipv6/ip6_output.c
>>>> +++ b/net/ipv6/ip6_output.c
>>>> @@ -61,9 +61,24 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
>>>> struct dst_entry *dst = skb_dst(skb);
>>>> struct net_device *dev = dst->dev;
>>>> const struct in6_addr *nexthop;
>>>> + unsigned int hh_len = LL_RESERVED_SPACE(dev);
>>>> struct neighbour *neigh;
>>>> int ret;
>>>>
>>>> + /* Be paranoid, rather than too clever. */
>>>> + if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
>>>> + struct sk_buff *skb2;
>>>> +
>>>> + skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
>>>
>>> why not use hh_len here?
>>
>> Is there a reason for the new skb? Why not pskb_expand_head()?
>
> pskb_expand_head() might crash, if skb is shared.
>
> We possibly can add a helper, factorizing all this,
> and eventually use pskb_expand_head() if safe.
Thank you for feedback, I'll do it in 2nd version.
Vasily Averin
On 7/7/21 8:30 PM, Jakub Kicinski wrote:
> On Wed, 7 Jul 2021 19:41:44 +0200 Eric Dumazet wrote:
>> On 7/7/21 6:42 PM, Jakub Kicinski wrote:
>>> On Wed, 7 Jul 2021 08:45:13 -0600 David Ahern wrote:
>>>> why not use hh_len here?
>>>
>>> Is there a reason for the new skb? Why not pskb_expand_head()?
>>
>>
>> pskb_expand_head() might crash, if skb is shared.
>>
>> We possibly can add a helper, factorizing all this,
>> and eventually use pskb_expand_head() if safe.
>
> Is there a strategically placed skb_share_check() somewhere further
> down? Otherwise there seems to be a lot of questionable skb_cow*()
> calls, also __skb_linearize() and skb_pad() are risky, no?
> Or is it that shared skbs are uncommon and syzbot doesn't hit them?
>
Some of us try hard to remove skb_get() occurrences,
but they tend to re-appear fast :/
Refs: commit a516993f0ac1694673412eb2d16a091eafa77d2a
("net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code")