kernel.git/drivers/net/gtp.c, branch linux-5.14.y

gtp: reset mac_header after decap

2021-06-28T19:44:17Z

For consistency with other L3 tunnel devices, reset the mac_header pointer after decapsulation. This makes the mac_header 0 bytes long, thus making it clear that this skb has no mac_header. Compile tested only. Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller

gtp: Fix a typo

2021-06-02T00:05:04Z

Suppport ==> Support Signed-off-by: Zheng Yongjun Signed-off-by: David S. Miller

net: icmp: pass zeroed opts from icmp{,v6}_ndo_send before sending

2021-02-23T19:29:52Z

The icmp{,v6}_send functions make all sorts of use of skb->cb, casting it with IPCB or IP6CB, assuming the skb to have come directly from the inet layer. But when the packet comes from the ndo layer, especially when forwarded, there's no telling what might be in skb->cb at that point. As a result, the icmp sending code risks reading bogus memory contents, which can result in nasty stack overflows such as this one reported by a user: panic+0x108/0x2ea __stack_chk_fail+0x14/0x20 __icmp_send+0x5bd/0x5c0 icmp_ndo_send+0x148/0x160 In icmp_send, skb->cb is cast with IPCB and an ip_options struct is read from it. The optlen parameter there is of particular note, as it can induce writes beyond bounds. There are quite a few ways that can happen in __ip_options_echo. For example: // sptr/skb are attacker-controlled skb bytes sptr = skb_network_header(skb); // dptr/dopt points to stack memory allocated by __icmp_send dptr = dopt->__data; // sopt is the corrupt skb->cb in question if (sopt->rr) { optlen = sptr[sopt->rr+1]; // corrupt skb->cb + skb->data soffset = sptr[sopt->rr+2]; // corrupt skb->cb + skb->data // this now writes potentially attacker-controlled data, over // flowing the stack: memcpy(dptr, sptr+sopt->rr, optlen); } In the icmpv6_send case, the story is similar, but not as dire, as only IP6CB(skb)->iif and IP6CB(skb)->dsthao are used. The dsthao case is worse than the iif case, but it is passed to ipv6_find_tlv, which does a bit of bounds checking on the value. This is easy to simulate by doing a `memset(skb->cb, 0x41, sizeof(skb->cb));` before calling icmp{,v6}_ndo_send, and it's only by good fortune and the rarity of icmp sending from that context that we've avoided reports like this until now. For example, in KASAN: BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0xa0e/0x12b0 Write of size 38 at addr ffff888006f1f80e by task ping/89 CPU: 2 PID: 89 Comm: ping Not tainted 5.10.0-rc7-debug+ #5 Call Trace: dump_stack+0x9a/0xcc print_address_description.constprop.0+0x1a/0x160 __kasan_report.cold+0x20/0x38 kasan_report+0x32/0x40 check_memory_region+0x145/0x1a0 memcpy+0x39/0x60 __ip_options_echo+0xa0e/0x12b0 __icmp_send+0x744/0x1700 Actually, out of the 4 drivers that do this, only gtp zeroed the cb for the v4 case, while the rest did not. So this commit actually removes the gtp-specific zeroing, while putting the code where it belongs in the shared infrastructure of icmp{,v6}_ndo_send. This commit fixes the issue by passing an empty IPCB or IP6CB along to the functions that actually do the work. For the icmp_send, this was already trivial, thanks to __icmp_send providing the plumbing function. For icmpv6_send, this required a tiny bit of refactoring to make it behave like the v4 case, after which it was straight forward. Fixes: a2b78e9b2cac ("sunvnet: generate ICMP PTMUD messages for smaller port MTUs") Reported-by: SinYu Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/netdev/CAF=yD-LOF116aHub6RMe8vB8ZpnrrnoTdqhobEx+bvoA8AsP0w@mail.gmail.com/T/ Signed-off-by: Jason A. Donenfeld Link: https://lore.kernel.org/r/20210223131858.72082-1-Jason@zx2c4.com Signed-off-by: Jakub Kicinski

gtp: update rx_length_errors for abnormally short packets

2021-02-04T17:29:58Z

Based on work by Pravin Shelar. Update appropriate stats when packet transmission isn't possible. Signed-off-by: Jonas Bonn Acked-by: Harald Welte Acked-by: Pravin B Shelar Signed-off-by: Jakub Kicinski

gtp: set device type

2021-02-04T17:29:58Z

Set the devtype to 'gtp' when setting up the link. Signed-off-by: Jonas Bonn Acked-by: Harald Welte Acked-by: Pravin B Shelar Signed-off-by: Jakub Kicinski

gtp: drop unnecessary call to skb_dst_drop

2021-02-04T17:29:58Z

The call to skb_dst_drop() is already done as part of udp_tunnel_xmit(). Signed-off-by: Jonas Bonn Acked-by: Harald Welte Acked-by: Pravin B Shelar Signed-off-by: Jakub Kicinski

gtp: really check namespaces before xmit

2021-02-04T17:29:58Z

Blindly assuming that packet transmission crosses namespaces results in skb marks being lost in the single namespace case. Signed-off-by: Jonas Bonn Acked-by: Harald Welte Acked-by: Pravin B Shelar Signed-off-by: Jakub Kicinski

gtp: include role in link info

2021-02-04T17:29:58Z

Querying link info for the GTP interface doesn't reveal in which "role" the device is set to operate. Include this information in the info query result. Signed-off-by: Jonas Bonn Acked-by: Harald Welte Acked-by: Pravin B Shelar Signed-off-by: Jakub Kicinski

gtp: set initial MTU

2021-02-04T17:29:57Z

The GTP link is brought up with a default MTU of zero. This can lead to some rather unexpected behaviour for users who are more accustomed to interfaces coming online with reasonable defaults. This patch sets an initial MTU for the GTP link of 1500 less worst-case tunnel overhead. Signed-off-by: Jonas Bonn Acked-by: Harald Welte Acked-by: Pravin B Shelar Signed-off-by: Jakub Kicinski

Revert "GTP: add support for flow based tunneling API"

2021-02-04T17:29:57Z

This reverts commit 9ab7e76aefc97a9aa664accb59d6e8dc5e52514a. This patch was committed without maintainer approval and despite a number of unaddressed concerns from review. There are several issues that impede the acceptance of this patch and that make a reversion of this particular instance of these changes the best way forward: i) the patch contains several logically separate changes that would be better served as smaller patches (for review purposes) ii) functionality like the handling of end markers has been introduced without further explanation iii) symmetry between the handling of GTPv0 and GTPv1 has been unnecessarily broken iv) the patchset produces 'broken' packets when extension headers are included v) there are no available userspace tools to allow for testing this functionality vi) there is an unaddressed Coverity report against the patch concering memory leakage vii) most importantly, the patch contains a large amount of superfluous churn that impedes other ongoing work with this driver This patch will be reworked into a series that aligns with other ongoing work and facilitates review. Signed-off-by: Jonas Bonn Acked-by: Harald Welte Acked-by: Pravin B Shelar Signed-off-by: Jakub Kicinski