* [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().
2024-04-15 22:20 [PATCH v1 net 0/5] ip: Fix warning in pskb_may_pull_reason() for tunnel devices Kuniyuki Iwashima
@ 2024-04-15 22:20 ` Kuniyuki Iwashima
2024-04-18 2:04 ` Jakub Kicinski
2024-04-15 22:20 ` [PATCH v1 net 2/5] vti: Pull header after checking skb->protocol in vti_tunnel_xmit() Kuniyuki Iwashima
` (3 subsequent siblings)
4 siblings, 1 reply; 12+ messages in thread
From: Kuniyuki Iwashima @ 2024-04-15 22:20 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern
Cc: Steffen Klassert, Herbert Xu, Willem de Bruijn, Kuniyuki Iwashima,
Kuniyuki Iwashima, netdev, syzkaller
syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
over sit0.
After nsh_gso_segment(), skb->data - skb->head was 138, on the other
hand, skb->network_header was 128.
Later, sit_tunnel_xmit() called pskb_inet_may_pull() for the skb, and
it caused underflow and triggered the warning in pskb_may_pull_reason().
pskb_network_may_pull(skb, nhlen)
`- pskb_may_pull(skb, skb_network_offset(skb) + nhlen)
-> skb_network_offset(skb) + nhlen
= skb_network_offset(skb) + 0 (because skb->protocol is not IPv4/IPv6)
= skb_network_header(skb) - skb->data
= skb->head + skb->network_header - skb->data
= 128 - 138
= -10
Let's check skb->protocol before pulling the next header in
sit_tunnel_xmit().
WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 pskb_may_pull include/linux/skbuff.h:2756 [inline]
WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
WARNING: CPU: 1 PID: 5300 at include/linux/skbuff.h:2740 sit_tunnel_xmit+0x1080/0x1fd8 net/ipv6/sit.c:1068
Modules linked in:
CPU: 1 PID: 5300 Comm: syz-executor.5 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pc : pskb_may_pull include/linux/skbuff.h:2756 [inline]
pc : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pc : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
pc : sit_tunnel_xmit+0x1080/0x1fd8 net/ipv6/sit.c:1068
lr : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
lr : pskb_may_pull include/linux/skbuff.h:2756 [inline]
lr : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
lr : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
lr : sit_tunnel_xmit+0x1080/0x1fd8 net/ipv6/sit.c:1068
sp : ffff8000aa017260
x29: ffff8000aa0173e0 x28: ffff00000cd0c000 x27: ffff000046200080
x26: ffff700015402e64 x25: 00000000fffffff6 x24: 1fffe00009835b7f
x23: dfff800000000000 x22: ffff00004c1adbf4 x21: ffff00004c1adbf8
x20: ffff00004c1adb40 x19: 1fffe00009835b7e x18: ffff800086d72d10
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001
x14: 1fffe0000a15c217 x13: 0000000000000000 x12: ffff8000aa017320
x11: 0000000000040000 x10: 0000000000000b86 x9 : ffff8000a2639000
x8 : 0000000000000b87 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000aa016c98 x4 : ffff800086d8b120 x3 : ffff800083f7f7d4
x2 : 0000000000000001 x1 : 00000000fffffff6 x0 : 0000000000000000
Call trace:
pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pskb_may_pull include/linux/skbuff.h:2756 [inline]
pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
sit_tunnel_xmit+0x1080/0x1fd8 net/ipv6/sit.c:1068
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x1a0/0x370 net/core/dev.c:3547
__dev_queue_xmit+0x12e8/0x2b04 net/core/dev.c:4335
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
packet_xmit+0x6c/0x31c net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3081 [inline]
packet_sendmsg+0x3818/0x4e50 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x324/0x470 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__arm64_sys_sendto+0xd8/0xf8 net/socket.c:2199
__invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152
el0_svc+0x30/0x78 arch/arm64/kernel/entry-common.c:712
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Reported-by: syzkaller <syzkaller@googlegroups.com>
Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
net/ipv6/sit.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 655c9b1a19b8..b83c28369d46 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1065,14 +1065,17 @@ static netdev_tx_t sit_tunnel_xmit__(struct sk_buff *skb,
static netdev_tx_t sit_tunnel_xmit(struct sk_buff *skb,
struct net_device *dev)
{
- if (!pskb_inet_may_pull(skb))
- goto tx_err;
-
switch (skb->protocol) {
case htons(ETH_P_IP):
+ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+ goto tx_err;
+
sit_tunnel_xmit__(skb, dev, IPPROTO_IPIP);
break;
case htons(ETH_P_IPV6):
+ if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+ goto tx_err;
+
ipip6_tunnel_xmit(skb, dev);
break;
#if IS_ENABLED(CONFIG_MPLS)
--
2.30.2
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().
2024-04-15 22:20 ` [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit() Kuniyuki Iwashima
@ 2024-04-18 2:04 ` Jakub Kicinski
2024-04-18 3:31 ` Kuniyuki Iwashima
0 siblings, 1 reply; 12+ messages in thread
From: Jakub Kicinski @ 2024-04-18 2:04 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, David Ahern,
Steffen Klassert, Herbert Xu, Willem de Bruijn, Kuniyuki Iwashima,
netdev, syzkaller
On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> over sit0.
>
> After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> hand, skb->network_header was 128.
is data offset > skb->network_header valid at this stage?
Can't we drop these packets instead?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().
2024-04-18 2:04 ` Jakub Kicinski
@ 2024-04-18 3:31 ` Kuniyuki Iwashima
2024-04-18 6:56 ` Eric Dumazet
0 siblings, 1 reply; 12+ messages in thread
From: Kuniyuki Iwashima @ 2024-04-18 3:31 UTC (permalink / raw)
To: kuba
Cc: davem, dsahern, edumazet, herbert, kuni1840, kuniyu, netdev,
pabeni, steffen.klassert, syzkaller, willemb
From: Jakub Kicinski <kuba@kernel.org>
Date: Wed, 17 Apr 2024 19:04:32 -0700
> On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > over sit0.
> >
> > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > hand, skb->network_header was 128.
>
> is data offset > skb->network_header valid at this stage?
> Can't we drop these packets instead?
I think that needs another fix on the NSH side.
But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
and friends, and then we should just drop it there without calling
pskb_inet_may_pull() that should not be called for non-IP skb.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().
2024-04-18 3:31 ` Kuniyuki Iwashima
@ 2024-04-18 6:56 ` Eric Dumazet
2024-04-18 7:00 ` Eric Dumazet
0 siblings, 1 reply; 12+ messages in thread
From: Eric Dumazet @ 2024-04-18 6:56 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: kuba, davem, dsahern, herbert, kuni1840, netdev, pabeni,
steffen.klassert, syzkaller, willemb
On Thu, Apr 18, 2024 at 5:32 AM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
>
> From: Jakub Kicinski <kuba@kernel.org>
> Date: Wed, 17 Apr 2024 19:04:32 -0700
> > On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > > over sit0.
> > >
> > > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > > hand, skb->network_header was 128.
> >
> > is data offset > skb->network_header valid at this stage?
> > Can't we drop these packets instead?
>
> I think that needs another fix on the NSH side.
>
> But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
> and friends, and then we should just drop it there without calling
> pskb_inet_may_pull() that should not be called for non-IP skb.
I dislike this patch series. I had this NSH bug for a while in my
queue, the bug is in NSH.
Also I added skb_vlan_inet_prepare() recently for a similar issue.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().
2024-04-18 6:56 ` Eric Dumazet
@ 2024-04-18 7:00 ` Eric Dumazet
2024-04-18 8:57 ` Paolo Abeni
0 siblings, 1 reply; 12+ messages in thread
From: Eric Dumazet @ 2024-04-18 7:00 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: kuba, davem, dsahern, herbert, kuni1840, netdev, pabeni,
steffen.klassert, syzkaller, willemb
On Thu, Apr 18, 2024 at 8:56 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Thu, Apr 18, 2024 at 5:32 AM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> >
> > From: Jakub Kicinski <kuba@kernel.org>
> > Date: Wed, 17 Apr 2024 19:04:32 -0700
> > > On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > > > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > > > over sit0.
> > > >
> > > > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > > > hand, skb->network_header was 128.
> > >
> > > is data offset > skb->network_header valid at this stage?
> > > Can't we drop these packets instead?
> >
> > I think that needs another fix on the NSH side.
> >
> > But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
> > and friends, and then we should just drop it there without calling
> > pskb_inet_may_pull() that should not be called for non-IP skb.
>
> I dislike this patch series. I had this NSH bug for a while in my
> queue, the bug is in NSH.
>
> Also I added skb_vlan_inet_prepare() recently for a similar issue.
Kuniyuki I am releasing the syzbot bug with a repro, if you have time to fix NSH
all your patches can go away I think.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().
2024-04-18 7:00 ` Eric Dumazet
@ 2024-04-18 8:57 ` Paolo Abeni
2024-04-18 17:02 ` Kuniyuki Iwashima
0 siblings, 1 reply; 12+ messages in thread
From: Paolo Abeni @ 2024-04-18 8:57 UTC (permalink / raw)
To: Eric Dumazet, Kuniyuki Iwashima
Cc: kuba, davem, dsahern, herbert, kuni1840, netdev, steffen.klassert,
syzkaller, willemb
On Thu, 2024-04-18 at 09:00 +0200, Eric Dumazet wrote:
> On Thu, Apr 18, 2024 at 8:56 AM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Thu, Apr 18, 2024 at 5:32 AM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> > >
> > > From: Jakub Kicinski <kuba@kernel.org>
> > > Date: Wed, 17 Apr 2024 19:04:32 -0700
> > > > On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > > > > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > > > > over sit0.
> > > > >
> > > > > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > > > > hand, skb->network_header was 128.
> > > >
> > > > is data offset > skb->network_header valid at this stage?
> > > > Can't we drop these packets instead?
> > >
> > > I think that needs another fix on the NSH side.
> > >
> > > But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
> > > and friends, and then we should just drop it there without calling
> > > pskb_inet_may_pull() that should not be called for non-IP skb.
> >
> > I dislike this patch series. I had this NSH bug for a while in my
> > queue, the bug is in NSH.
> >
> > Also I added skb_vlan_inet_prepare() recently for a similar issue.
>
> Kuniyuki I am releasing the syzbot bug with a repro, if you have time to fix NSH
> all your patches can go away I think.
I agree a specific/smaller scope fix on in nsh should be preferred
here.
Thanks,
Paolo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit().
2024-04-18 8:57 ` Paolo Abeni
@ 2024-04-18 17:02 ` Kuniyuki Iwashima
0 siblings, 0 replies; 12+ messages in thread
From: Kuniyuki Iwashima @ 2024-04-18 17:02 UTC (permalink / raw)
To: pabeni
Cc: davem, dsahern, edumazet, herbert, kuba, kuni1840, kuniyu, netdev,
steffen.klassert, syzkaller, willemb
From: Paolo Abeni <pabeni@redhat.com>
> On Thu, 2024-04-18 at 09:00 +0200, Eric Dumazet wrote:
> > On Thu, Apr 18, 2024 at 8:56 AM Eric Dumazet <edumazet@google.com> wrote:
> > >
> > > On Thu, Apr 18, 2024 at 5:32 AM Kuniyuki Iwashima <kuniyu@amazon.com> wrote:
> > > >
> > > > From: Jakub Kicinski <kuba@kernel.org>
> > > > Date: Wed, 17 Apr 2024 19:04:32 -0700
> > > > > On Mon, 15 Apr 2024 15:20:37 -0700 Kuniyuki Iwashima wrote:
> > > > > > syzkaller crafted a GSO packet of ETH_P_8021AD + ETH_P_NSH and sent it
> > > > > > over sit0.
> > > > > >
> > > > > > After nsh_gso_segment(), skb->data - skb->head was 138, on the other
> > > > > > hand, skb->network_header was 128.
> > > > >
> > > > > is data offset > skb->network_header valid at this stage?
> > > > > Can't we drop these packets instead?
> > > >
> > > > I think that needs another fix on the NSH side.
> > > >
> > > > But even with that, we can still pass valid L2 skb to sit_tunnel_xmit()
> > > > and friends, and then we should just drop it there without calling
> > > > pskb_inet_may_pull() that should not be called for non-IP skb.
> > >
> > > I dislike this patch series. I had this NSH bug for a while in my
> > > queue, the bug is in NSH.
> > >
> > > Also I added skb_vlan_inet_prepare() recently for a similar issue.
> >
> > Kuniyuki I am releasing the syzbot bug with a repro, if you have time to fix NSH
> > all your patches can go away I think.
Thanks for sharing the repro, Eric!
>
> I agree a specific/smaller scope fix on in nsh should be preferred
Hmm.. I think the bug is both in NSH and the tunnel xmit
functions in this series.
geneve is in a bit differnt position because L2 skb is sane
for geneve, and it needs to inspect vlan and the upper layer.
However, L3 tunnels should validate skb->protocol first before
accessing skb->network_header, otherwise that could trigger KMSAN.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v1 net 2/5] vti: Pull header after checking skb->protocol in vti_tunnel_xmit().
2024-04-15 22:20 [PATCH v1 net 0/5] ip: Fix warning in pskb_may_pull_reason() for tunnel devices Kuniyuki Iwashima
2024-04-15 22:20 ` [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit() Kuniyuki Iwashima
@ 2024-04-15 22:20 ` Kuniyuki Iwashima
2024-04-15 22:20 ` [PATCH v1 net 3/5] ip6_vti: Pull header after checking skb->protocol in vti6_tnl_xmit() Kuniyuki Iwashima
` (2 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: Kuniyuki Iwashima @ 2024-04-15 22:20 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern
Cc: Steffen Klassert, Herbert Xu, Willem de Bruijn, Kuniyuki Iwashima,
Kuniyuki Iwashima, netdev, syzkaller
syzkaller demonstrated the underflow in pskb_network_may_pull()
by sending a crafted VLAN packet over the tunnel device.
Let's check skb->protocol before pulling the next header in
vti_tunnel_xmit().
WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 pskb_may_pull include/linux/skbuff.h:2756 [inline]
WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
WARNING: CPU: 1 PID: 4534 at include/linux/skbuff.h:2740 vti_tunnel_xmit+0xd48/0x14b4 net/ipv4/ip_vti.c:283
Modules linked in:
CPU: 1 PID: 4534 Comm: syz-executor.1 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pc : pskb_may_pull include/linux/skbuff.h:2756 [inline]
pc : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pc : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
pc : vti_tunnel_xmit+0xd48/0x14b4 net/ipv4/ip_vti.c:283
lr : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
lr : pskb_may_pull include/linux/skbuff.h:2756 [inline]
lr : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
lr : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
lr : vti_tunnel_xmit+0xd48/0x14b4 net/ipv4/ip_vti.c:283
sp : ffff8000a99372a0
x29: ffff8000a99373e0 x28: ffff00000d188838 x27: ffff700015326e64
x26: ffff000061930080 x25: dfff800000000000 x24: ffff8000a9937320
x23: 0000000000000000 x22: ffff00000d188834 x21: 00000000fffffff6
x20: ffff00000d188780 x19: ffff000017580000 x18: ffff800086d72d10
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001
x14: 1fffe000029ce017 x13: 0000000000000000 x12: 0000000000000001
x11: 0000000000040000 x10: 0000000000000b7f x9 : ffff80008a3fa000
x8 : 0000000000000b80 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000a9936c98 x4 : ffff800086d8b120 x3 : ffff800083f7f7d4
x2 : 0000000000000001 x1 : 00000000fffffff6 x0 : 0000000000000000
Call trace:
pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pskb_may_pull include/linux/skbuff.h:2756 [inline]
pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
vti_tunnel_xmit+0xd48/0x14b4 net/ipv4/ip_vti.c:283
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x1a0/0x370 net/core/dev.c:3547
__dev_queue_xmit+0x12e8/0x2b04 net/core/dev.c:4335
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
packet_xmit+0x6c/0x31c net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3081 [inline]
packet_sendmsg+0x3818/0x4e50 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x324/0x470 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__arm64_sys_sendto+0xd8/0xf8 net/socket.c:2199
__invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152
el0_svc+0x30/0x78 arch/arm64/kernel/entry-common.c:712
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Reported-by: syzkaller <syzkaller@googlegroups.com>
Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
net/ipv4/ip_vti.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index ee587adb169f..8070d0c440f6 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -280,17 +280,20 @@ static netdev_tx_t vti_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
struct ip_tunnel *tunnel = netdev_priv(dev);
struct flowi fl;
- if (!pskb_inet_may_pull(skb))
- goto tx_err;
-
memset(&fl, 0, sizeof(fl));
switch (skb->protocol) {
case htons(ETH_P_IP):
+ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+ goto tx_err;
+
memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
xfrm_decode_session(dev_net(dev), skb, &fl, AF_INET);
break;
case htons(ETH_P_IPV6):
+ if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+ goto tx_err;
+
memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
xfrm_decode_session(dev_net(dev), skb, &fl, AF_INET6);
break;
--
2.30.2
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH v1 net 3/5] ip6_vti: Pull header after checking skb->protocol in vti6_tnl_xmit().
2024-04-15 22:20 [PATCH v1 net 0/5] ip: Fix warning in pskb_may_pull_reason() for tunnel devices Kuniyuki Iwashima
2024-04-15 22:20 ` [PATCH v1 net 1/5] sit: Pull header after checking skb->protocol in sit_tunnel_xmit() Kuniyuki Iwashima
2024-04-15 22:20 ` [PATCH v1 net 2/5] vti: Pull header after checking skb->protocol in vti_tunnel_xmit() Kuniyuki Iwashima
@ 2024-04-15 22:20 ` Kuniyuki Iwashima
2024-04-15 22:20 ` [PATCH v1 net 4/5] ipip: Pull header after checking skb->protocol in ipip_tunnel_xmit() Kuniyuki Iwashima
2024-04-15 22:20 ` [PATCH v1 net 5/5] ip6_tunnel: Pull header after checking skb->protocol in ip6_tnl_start_xmit() Kuniyuki Iwashima
4 siblings, 0 replies; 12+ messages in thread
From: Kuniyuki Iwashima @ 2024-04-15 22:20 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern
Cc: Steffen Klassert, Herbert Xu, Willem de Bruijn, Kuniyuki Iwashima,
Kuniyuki Iwashima, netdev, syzkaller
syzkaller demonstrated the underflow in pskb_network_may_pull()
by sending a crafted VLAN packet over the tunnel device.
Let's check skb->protocol before pulling the next header in
vti6_tnl_xmit().
WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 pskb_may_pull include/linux/skbuff.h:2756 [inline]
WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
WARNING: CPU: 0 PID: 722 at include/linux/skbuff.h:2740 vti6_tnl_xmit+0x100c/0x16c0 net/ipv6/ip6_vti.c:560
Modules linked in:
CPU: 0 PID: 722 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pc : pskb_may_pull include/linux/skbuff.h:2756 [inline]
pc : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pc : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
pc : vti6_tnl_xmit+0x100c/0x16c0 net/ipv6/ip6_vti.c:560
lr : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
lr : pskb_may_pull include/linux/skbuff.h:2756 [inline]
lr : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
lr : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
lr : vti6_tnl_xmit+0x100c/0x16c0 net/ipv6/ip6_vti.c:560
sp : ffff8000a86d7280
x29: ffff8000a86d73e0 x28: ffff7000150dae64 x27: ffff8000a86d7320
x26: ffff00004fdd0010 x25: dfff800000000000 x24: 00000000fffffff6
x23: ffff00000a0ae478 x22: ffff00000a0ae498 x21: ffff00000a0ae474
x20: ffff00000a0ae3c0 x19: ffff0000178d6000 x18: ffff800086d72d10
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001
x14: 1fffe0000958b817 x13: 0000000000000000 x12: 0000000000000001
x11: 0000000000040000 x10: 0000000000000b8a x9 : ffff80008e699000
x8 : 0000000000000b8b x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000a86d6c98 x4 : ffff800086d8b120 x3 : ffff800083f7f7d4
x2 : 0000000000000001 x1 : 00000000fffffff6 x0 : 0000000000000000
Call trace:
pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pskb_may_pull include/linux/skbuff.h:2756 [inline]
pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
vti6_tnl_xmit+0x100c/0x16c0 net/ipv6/ip6_vti.c:560
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x1a0/0x370 net/core/dev.c:3547
__dev_queue_xmit+0x12e8/0x2b04 net/core/dev.c:4335
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
packet_xmit+0x6c/0x31c net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3081 [inline]
packet_sendmsg+0x3818/0x4e50 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x324/0x470 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__arm64_sys_sendto+0xd8/0xf8 net/socket.c:2199
__invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152
el0_svc+0x30/0x78 arch/arm64/kernel/entry-common.c:712
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Reported-by: syzkaller <syzkaller@googlegroups.com>
Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
net/ipv6/ip6_vti.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 7f4f976aa24a..98c738eb6166 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -557,13 +557,13 @@ vti6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
struct flowi fl;
int ret;
- if (!pskb_inet_may_pull(skb))
- goto tx_err;
-
memset(&fl, 0, sizeof(fl));
switch (skb->protocol) {
case htons(ETH_P_IPV6):
+ if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+ goto tx_err;
+
if ((t->parms.proto != IPPROTO_IPV6 && t->parms.proto != 0) ||
vti6_addr_conflict(t, ipv6_hdr(skb)))
goto tx_err;
@@ -572,6 +572,9 @@ vti6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
xfrm_decode_session(dev_net(dev), skb, &fl, AF_INET6);
break;
case htons(ETH_P_IP):
+ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+ goto tx_err;
+
memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
xfrm_decode_session(dev_net(dev), skb, &fl, AF_INET);
break;
--
2.30.2
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH v1 net 4/5] ipip: Pull header after checking skb->protocol in ipip_tunnel_xmit().
2024-04-15 22:20 [PATCH v1 net 0/5] ip: Fix warning in pskb_may_pull_reason() for tunnel devices Kuniyuki Iwashima
` (2 preceding siblings ...)
2024-04-15 22:20 ` [PATCH v1 net 3/5] ip6_vti: Pull header after checking skb->protocol in vti6_tnl_xmit() Kuniyuki Iwashima
@ 2024-04-15 22:20 ` Kuniyuki Iwashima
2024-04-15 22:20 ` [PATCH v1 net 5/5] ip6_tunnel: Pull header after checking skb->protocol in ip6_tnl_start_xmit() Kuniyuki Iwashima
4 siblings, 0 replies; 12+ messages in thread
From: Kuniyuki Iwashima @ 2024-04-15 22:20 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern
Cc: Steffen Klassert, Herbert Xu, Willem de Bruijn, Kuniyuki Iwashima,
Kuniyuki Iwashima, netdev, syzkaller
syzkaller demonstrated the underflow in pskb_network_may_pull()
by sending a crafted VLAN packet over the tunnel device.
Let's check skb->protocol before pulling the next header in
ipip_tunnel_xmit().
WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 pskb_may_pull include/linux/skbuff.h:2756 [inline]
WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
WARNING: CPU: 0 PID: 4406 at include/linux/skbuff.h:2740 ipip_tunnel_xmit+0x2d4/0x430 net/ipv4/ipip.c:281
Modules linked in:
CPU: 0 PID: 4406 Comm: syz-executor.1 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: linux,dummy-virt (DT)
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pc : pskb_may_pull include/linux/skbuff.h:2756 [inline]
pc : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pc : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
pc : ipip_tunnel_xmit+0x2d4/0x430 net/ipv4/ipip.c:281
lr : pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
lr : pskb_may_pull include/linux/skbuff.h:2756 [inline]
lr : pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
lr : pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
lr : ipip_tunnel_xmit+0x2d4/0x430 net/ipv4/ipip.c:281
sp : ffff8000a82673f0
x29: ffff8000a82673f0 x28: ffff00000fc24140 x27: ffff00006ab166ba
x26: 1fffe00001f8483e x25: dfff800000000000 x24: ffff00003b898080
x23: 0000000000000000 x22: 00000000fffffff6 x21: ffff00000fc241f4
x20: ffff00000fc24140 x19: ffff000046206000 x18: ffff800086d72d10
x17: 00000000008a008a x16: 008a4f8900000000 x15: 0000000000000001
x14: 1ffff00011028fbc x13: 0000000000000004 x12: 0000000000000001
x11: 0000000000040000 x10: 0000000000000f68 x9 : ffff80008d25a000
x8 : 0000000000000f69 x7 : ffff8000800477bc x6 : ffff8000800479b8
x5 : ffff0000687ca948 x4 : ffff8000a8267028 x3 : ffff800083f7f890
x2 : 0000000000000001 x1 : 00000000fffffff6 x0 : 0000000000000000
Call trace:
pskb_may_pull_reason include/linux/skbuff.h:2740 [inline]
pskb_may_pull include/linux/skbuff.h:2756 [inline]
pskb_network_may_pull include/linux/skbuff.h:3077 [inline]
pskb_inet_may_pull include/net/ip_tunnels.h:361 [inline]
ipip_tunnel_xmit+0x2d4/0x430 net/ipv4/ipip.c:281
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x1a0/0x370 net/core/dev.c:3547
__dev_queue_xmit+0x12e8/0x2b04 net/core/dev.c:4335
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
packet_xmit+0x6c/0x31c net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3081 [inline]
packet_sendmsg+0x3818/0x4e50 net/packet/af_packet.c:3113
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x324/0x470 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__arm64_sys_sendto+0xd8/0xf8 net/socket.c:2199
__invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152
el0_svc+0x30/0x78 arch/arm64/kernel/entry-common.c:712
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Reported-by: syzkaller <syzkaller@googlegroups.com>
Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
net/ipv4/ipip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index f2696eaadbe6..3f96364d65fd 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -278,11 +278,11 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb,
const struct iphdr *tiph = &tunnel->parms.iph;
u8 ipproto;
- if (!pskb_inet_may_pull(skb))
- goto tx_error;
-
switch (skb->protocol) {
case htons(ETH_P_IP):
+ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+ goto tx_error;
+
ipproto = IPPROTO_IPIP;
break;
#if IS_ENABLED(CONFIG_MPLS)
--
2.30.2
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH v1 net 5/5] ip6_tunnel: Pull header after checking skb->protocol in ip6_tnl_start_xmit().
2024-04-15 22:20 [PATCH v1 net 0/5] ip: Fix warning in pskb_may_pull_reason() for tunnel devices Kuniyuki Iwashima
` (3 preceding siblings ...)
2024-04-15 22:20 ` [PATCH v1 net 4/5] ipip: Pull header after checking skb->protocol in ipip_tunnel_xmit() Kuniyuki Iwashima
@ 2024-04-15 22:20 ` Kuniyuki Iwashima
4 siblings, 0 replies; 12+ messages in thread
From: Kuniyuki Iwashima @ 2024-04-15 22:20 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern
Cc: Steffen Klassert, Herbert Xu, Willem de Bruijn, Kuniyuki Iwashima,
Kuniyuki Iwashima, netdev
syzkaller demonstrated the underflow in pskb_network_may_pull()
by sending a crafted VLAN packet over tunnel devices: sit, ipip,
vti, and vti6.
The same warning will be triggered for ip6tnl, so let's check
skb->protocol before pulling the next header in ip6_tnl_start_xmit().
Fixes: cb9f1b783850 ("ip: validate header length on virtual device xmit")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
net/ipv6/ip6_tunnel.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index e9cc315832cb..81be7a5be6c5 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1424,14 +1424,17 @@ ip6_tnl_start_xmit(struct sk_buff *skb, struct net_device *dev)
u8 ipproto;
int ret;
- if (!pskb_inet_may_pull(skb))
- goto tx_err;
-
switch (skb->protocol) {
case htons(ETH_P_IP):
+ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)))
+ goto tx_err;
+
ipproto = IPPROTO_IPIP;
break;
case htons(ETH_P_IPV6):
+ if (!pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
+ goto tx_err;
+
if (ip6_tnl_addr_conflict(t, ipv6_hdr(skb)))
goto tx_err;
ipproto = IPPROTO_IPV6;
--
2.30.2
^ permalink raw reply related [flat|nested] 12+ messages in thread