From: Stanislav Fomichev <sdf@google.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, jasowang@redhat.com, brouer@redhat.com,
mst@redhat.com, edumazet@google.com,
Stanislav Fomichev <sdf@google.com>,
syzbot <syzkaller@googlegroups.com>
Subject: [PATCH net 2/2] tun: always set skb->dev to tun->dev
Date: Mon, 7 Jan 2019 12:02:24 -0800 [thread overview]
Message-ID: <20190107200224.220467-2-sdf@google.com> (raw)
In-Reply-To: <20190107200224.220467-1-sdf@google.com>
While debugging previous issue I noticed that commit 90e33d459407 ("tun:
enable napi_gro_frags() for TUN/TAP driver") started conditionally
(!frags) calling eth_type_trans(skb, tun->dev) for IFF_TAP case. Since
eth_type_trans sets skb->dev, some skbs can now have NULL skb->dev.
Fix that by always setting skb->dev unconditionally.
The syzbot fails with the following trace:
WARNING: CPU: 0 PID: 11136 at net/core/flow_dissector.c:764
skb_flow_dissect_flow_keys_basic include/linux/skbuff.h:1240 [inline]
skb_probe_transport_header include/linux/skbuff.h:2403 [inline]
tun_get_user+0x2d4a/0x4250 drivers/net/tun.c:1906
tun_chr_write_iter+0xb9/0x160 drivers/net/tun.c:1993
call_write_iter include/linux/fs.h:1808 [inline]
new_sync_write fs/read_write.c:474 [inline]
But I don't think there is an actual issue since we exercise flow
dissector via eth_get_headlen which doesn't use skb (and hence BPF flow
dissector). But let's still properly set skb->dev so we don't have
any problems going forward.
Reported-by: syzbot <syzkaller@googlegroups.com>
Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
drivers/net/tun.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7875f06011f2..af34baf978f3 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1899,6 +1899,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
return -EINVAL;
}
+ skb->dev = tun->dev;
switch (tun->flags & TUN_TYPE_MASK) {
case IFF_TUN:
if (tun->flags & IFF_NO_PI) {
@@ -1920,7 +1921,6 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_reset_mac_header(skb);
skb->protocol = pi.proto;
- skb->dev = tun->dev;
break;
case IFF_TAP:
if (!frags)
--
2.20.1.97.g81188d93c3-goog
next prev parent reply other threads:[~2019-01-07 20:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 20:02 [PATCH net 1/2] tun: hold napi_mutex for all napi operations Stanislav Fomichev
2019-01-07 20:02 ` Stanislav Fomichev [this message]
2019-01-07 20:22 ` Eric Dumazet
2019-01-07 21:02 ` Stanislav Fomichev
2019-01-07 21:10 ` Eric Dumazet
2019-01-07 21:29 ` Stanislav Fomichev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190107200224.220467-2-sdf@google.com \
--to=sdf@google.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=syzkaller@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).