- 15 Jan, 2017 38 commits
-
-
Greg Kroah-Hartman authored
commit 1ebb7114 upstream. Make sure we have enough of a report structure to validate before looking at it. Reported-by:
Benoit Camredon <benoit.camredon@airbus.com> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
David Ahern authored
[ Upstream commit 24c63bbc ] Frank reported that vrf devices can be created with a table id of 0. This breaks many of the run time table id checks and should not be allowed. Detect this condition at create time and fail with EINVAL. Fixes: 193125db ("net: Introduce VRF device driver") Reported-by:
Frank Kellermann <frank.kellermann@atos.net> Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Ahern authored
[ Upstream commit 7a18c5b9 ] fib_select_path does not call fib_select_multipath if oif is set in the flow struct. For VRF use cases oif is always set, so multipath route selection is bypassed. Use the FLOWI_FLAG_SKIP_NH_OIF to skip the oif check similar to what is done in fib_table_lookup. Add saddr and proto to the flow struct for the fib lookup done by the VRF driver to better match hash computation for a flow. Fixes: 613d09b3 ("net: Use VRF device index for lookups on TX") Signed-off-by:
-
Gil Rockah authored
[ Upstream commit 0bbcc0a8 ] When trying to do interface down or changing interface configuration under heavy traffic, some of the adaptive moderation corner cases can occur and leave a WARN_ONCE call trace in the kernel log. Those WARN_ONCE are meant for debug only, and should have been inserted only under debug. We avoid such call traces by removing those WARN_ONCE. Fixes: cb3c7fd4 ("net/mlx5e: Support adaptive RX coalescing") Signed-off-by:
Gil Rockah <gilr@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Herbert Xu authored
[ Upstream commit 57ea52a8 ] The GRO fast path caches the frag0 address. This address becomes invalid if frag0 is modified by pskb_may_pull or its variants. So whenever that happens we must disable the frag0 optimization. This is usually done through the combination of gro_header_hard and gro_header_slow, however, the IPv6 extension header path did the pulling directly and would continue to use the GRO fast path incorrectly. This patch fixes it by disabling the fast path when we enter the IPv6 extension header path. Fixes: 78a478d0 ("gro: Inline skb_gro_header and cache frag0 virtual address") Reported-by:
Slava Shwartsman <slavash@mellanox.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 7cfd5fd5 ] On 32bit arches, (skb->end - skb->data) is not 'unsigned int', so we shall use min_t() instead of min() to avoid a compiler error. Fixes: 1272ce87 ("gro: Enter slow-path if there is no tailroom") Reported-by:
kernel test robot <fengguang.wu@intel.com> Signed-off-by:
-
Herbert Xu authored
[ Upstream commit 1272ce87 ] The GRO path has a fast-path where we avoid calling pskb_may_pull and pskb_expand by directly accessing frag0. However, this should only be done if we have enough tailroom in the skb as otherwise we'll have to expand it later anyway. This patch adds the check by capping frag0_len with the skb tailroom. Fixes: cb18978c ("gro: Open-code final pskb_may_pull") Reported-by:
-
Anna, Suman authored
[ Upstream commit 5d722b30 ] Commit bdabad3e ("net: Add Qualcomm IPC router") introduced a new address family. Update the family name tables accordingly so that the lockdep initialization can use the proper names for this family. Cc: Courtney Cavin <courtney.cavin@sonymobile.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Suman Anna <s-anna@ti.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit faf3a932 ] It is perfectly possible to have non zero indexed switches being present in a DSA switch tree, in such a case, we will be deferencing a NULL pointer while dsa_cpu_port_ethtool_{setup,restore}. Be more defensive and ensure that dst->ds[0] is valid before doing anything with it. Fixes: 0c73c523 ("net: dsa: Initialize CPU port ethtool ops per tree") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
hayeswang authored
[ Upstream commit 75dc692e ] Pause the rx and make sure the rx fifo is empty when the autosuspend occurs. If the rx data comes when the driver is canceling the rx urb, the host controller would stop getting the data from the device and continue it after next rx urb is submitted. That is, one continuing data is split into two different urb buffers. That let the driver take the data as a rx descriptor, and unexpected behavior happens. Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
-
hayeswang authored
[ Upstream commit 8fb28061 ] Split rtl8152_suspend() into rtl8152_system_suspend() and rtl8152_rumtime_suspend(). Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 2cfe8f82 ] We are implementing a MDIO bus which is behind another one, so use the nested version of the accessors to get lockdep annotations correct. Fixes: 461cd1b0 ("net: dsa: bcm_sf2: Register our slave MDIO bus") Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit a4c61b92 ] We make the bcm_sf2 driver override ds->ops which points to b53_switch_ops since b53_switch_alloc() did the assignent. This is all well and good until a second b53 switch comes in, and ends up using the bcm_sf2 operations. Make a proper local copy, substitute the ds->ops pointer and then override the operations. Fixes: f458995b ("net: dsa: bcm_sf2: Utilize core B53 driver when possible") Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 9d5ecb09 ] If after too many passes still no image could be emitted, then swap back to the original program as we do in all other cases and don't use the one with blinding. Fixes: 959a7579 ("bpf, x86: add support for constant blinding") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
David Ahern authored
[ Upstream commit 926d93a3 ] The move from rx-handler to L3 receive handler inadvertantly dropped the rx counters. Restore them. Fixes: 74b20582 ("net: l3mdev: Add hook in ip and ipv6") Reported-by:
Dinesh Dutt <ddutt@cumulusnetworks.com> Signed-off-by:
-
Alexander Duyck authored
[ Upstream commit 5350d54f ] In the case of custom rules being present we need to handle the case of the LOCAL table being intialized after the new rule has been added. To address that I am adding a new check so that we can make certain we don't use an alias of MAIN for LOCAL when allocating a new table. Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse") Reported-by:
Oliver Brunel <jjk@jjacky.com> Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
Michal Tesar authored
[ Upstream commit 7ababb78 ] 5.2. Action on Reception of a Query When a system receives a Query, it does not respond immediately. Instead, it delays its response by a random amount of time, bounded by the Max Resp Time value derived from the Max Resp Code in the received Query message. A system may receive a variety of Queries on different interfaces and of different kinds (e.g., General Queries, Group-Specific Queries, and Group-and-Source-Specific Queries), each of which may require its own delayed response. Before scheduling a response to a Query, the system must first consider previously scheduled pending responses and in many cases schedule a combined response. Therefore, the system must be able to maintain the following state: o A timer per interface for scheduling responses to General Queries. o A per-group and interface timer for scheduling responses to Group- Specific and Group-and-Source-Specific Queries. o A per-group and interface list of sources to be reported in the response to a Group-and-Source-Specific Query. When a new Query with the Router-Alert option arrives on an interface, provided the system has state to report, a delay for a response is randomly selected in the range (0, [Max Resp Time]) where Max Resp Time is derived from Max Resp Code in the received Query message. The following rules are then used to determine if a Report needs to be scheduled and the type of Report to schedule. The rules are considered in order and only the first matching rule is applied. 1. If there is a pending response to a previous General Query scheduled sooner than the selected delay, no additional response needs to be scheduled. 2. If the received Query is a General Query, the interface timer is used to schedule a response to the General Query after the selected delay. Any previously pending response to a General Query is canceled. --8<-- Currently the timer is rearmed with new random expiration time for every incoming query regardless of possibly already pending report. Which is not aligned with the above RFE. It also might happen that higher rate of incoming queries can postpone the report after the expiration time of the first query causing group membership loss. Now the per interface general query timer is rearmed only when there is no pending report already scheduled on that interface or the newly selected expiration time is before the already pending scheduled report. Signed-off-by:
Michal Tesar <mtesar@redhat.com> Signed-off-by:
-
Ian Kumlien authored
[ Upstream commit d0af6834 ] __skb_flow_dissect can be called with a skb or a data packet, either can be NULL. All calls seems to have been moved to __skb_header_pointer except the pptp handling which is still calling skb_header_pointer. skb_header_pointer will use skb->data and thus: [ 109.556866] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [ 109.557102] IP: [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.557263] PGD 0 [ 109.557338] [ 109.557484] Oops: 0000 [#1] SMP [ 109.557562] Modules linked in: chaoskey [ 109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79 [ 109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015 [ 109.557957] task: ffff94085c27bc00 task.stack: ffffb745c0068000 [ 109.558041] RIP: 0010:[<ffffffff88dc02f8>] [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.558203] RSP: 0018:ffff94087fc83d40 EFLAGS: 00010206 [ 109.558286] RAX: 0000000000000130 RBX: ffffffff8975bf80 RCX: ffff94084fab6800 [ 109.558373] RDX: 0000000000000010 RSI: 000000000000000c RDI: 0000000000000000 [ 109.558460] RBP: 0000000000000b88 R08: 0000000000000000 R09: 0000000000000022 [ 109.558547] R10: 0000000000000008 R11: ffff94087fc83e04 R12: 0000000000000000 [ 109.558763] R13: ffff94084fab6800 R14: ffff94087fc83e04 R15: 000000000000002f [ 109.558979] FS: 0000000000000000(0000) GS:ffff94087fc80000(0000) knlGS:0000000000000000 [ 109.559326] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 109.559539] CR2: 0000000000000080 CR3: 0000000281809000 CR4: 00000000001026e0 [ 109.559753] Stack: [ 109.559957] 000000000000000c ffff94084fab6822 0000000000000001 ffff94085c2b5fc0 [ 109.560578] 0000000000000001 0000000000002000 0000000000000000 0000000000000000 [ 109.561200] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 109.561820] Call Trace: [ 109.562027] <IRQ> [ 109.562108] [<ffffffff88dfb4fa>] ? eth_get_headlen+0x7a/0xf0 [ 109.562522] [<ffffffff88c5a35a>] ? igb_poll+0x96a/0xe80 [ 109.562737] [<ffffffff88dc912b>] ? net_rx_action+0x20b/0x350 [ 109.562953] [<ffffffff88546d68>] ? __do_softirq+0xe8/0x280 [ 109.563169] [<ffffffff8854704a>] ? irq_exit+0xaa/0xb0 [ 109.563382] [<ffffffff8847229b>] ? do_IRQ+0x4b/0xc0 [ 109.563597] [<ffffffff8902d4ff>] ? common_interrupt+0x7f/0x7f [ 109.563810] <EOI> [ 109.563890] [<ffffffff88d57530>] ? cpuidle_enter_state+0x130/0x2c0 [ 109.564304] [<ffffffff88d57520>] ? cpuidle_enter_state+0x120/0x2c0 [ 109.564520] [<ffffffff8857eacf>] ? cpu_startup_entry+0x19f/0x1f0 [ 109.564737] [<ffffffff8848d55a>] ? start_secondary+0x12a/0x140 [ 109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00 00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2 04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84 24 84 [ 109.569959] RIP [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0 [ 109.570245] RSP <ffff94087fc83d40> [ 109.570453] CR2: 0000000000000080 Fixes: ab10dccb ("rps: Inspect PPTP encapsulated by GRE to get flow hash") Signed-off-by:
Ian Kumlien <ian.kumlien@gmail.com> Signed-off-by:
-
Reiter Wolfgang authored
[ Upstream commit 3b48ab22 ] Final nlmsg_len field update must reflect inserted net_dm_drop_point data. This patch depends on previous patch: "drop_monitor: add missing call to genlmsg_end" Signed-off-by:
Reiter Wolfgang <wr0112358@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Reiter Wolfgang authored
[ Upstream commit 4200462d ] Update nlmsg_len field with genlmsg_end to enable userspace processing using nlmsg_next helper. Also adds error handling. Signed-off-by:
-
David Ahern authored
[ Upstream commit f5a0aab8 ] IPv4 output routes already use l3mdev device instead of loopback for dst's if it is applicable. Change local input routes to do the same. This fixes icmp responses for unreachable UDP ports which are directed to the wrong table after commit 9d1a6c4e because local_input routes use the loopback device. Moving from ingress device to loopback loses the L3 domain causing responses based on the dst to get to lost. Fixes: 9d1a6c4e ("net: icmp_route_lookup should use rt dev to determine L3 domain") Signed-off-by:
-
Wei Zhang authored
[ Upstream commit f0c16ba8 ] When we send a packet for our own local address on a non-loopback interface (e.g. eth0), due to the change had been introduced from commit 0b922b7a ("net: original ingress device index in PKTINFO"), the original ingress device index would be set as the loopback interface. However, the packet should be considered as if it is being arrived via the sending interface (eth0), otherwise it would break the expectation of the userspace application (e.g. the DHCPRELEASE message from dhcp_release binary would be ignored by the dnsmasq daemon, since it come from lo which is not the interface dnsmasq bind to) Fixes: 0b922b7a ("net: original ingress device index in PKTINFO") Acked-by:
Wei Zhang <asuka.com@163.com> Signed-off-by:
-
Mathias Krause authored
[ Upstream commit 4775cc1f ] We miss to check if the netlink message is actually big enough to contain a struct if_stats_msg. Add a check to prevent userland from sending us short messages that would make us access memory beyond the end of the message. Fixes: 10c9ead9 ("rtnetlink: add new RTM_GETSTATS message to dump...") Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
-
Saeed Mahameed authored
[ Upstream commit 37f304d1 ] Disable netdev should come after it was closed, although no harm of doing it before -hence the MLX5E_STATE_DESTROYING bit- but it is more natural this way. Fixes: 26e59d80 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks") Signed-off-by:
Mohamad Haj Yahia <mohamad@mellanox.com> Signed-off-by:
-
Saeed Mahameed authored
[ Upstream commit 610e89e0 ] Skip setting netdev vxlan ports and netdev rx_mode on driver load when netdev is not yet registered. Synchronizing with netdev state is needed only on reset flow where the netdev remains registered for the whole reset period. This also fixes an access before initialization of net_device.addr_list_lock - which for some reason initialized on register_netdev - where we queued set_rx_mode work on driver load before netdev registration. Fixes: 26e59d80 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks") Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by:
-
Mohamad Haj Yahia authored
[ Upstream commit ccce1700 ] Need to check that VF mac address entered by the admin user is either zero or unicast mac. Multicast mac addresses are prohibited. Fixes: 77256579 ('net/mlx5: E-Switch, Introduce Vport administration functions') Signed-off-by:
-
Maor Gottlieb authored
[ Upstream commit 077b1e80 ] We need to mask the destination mac value with the destination mac mask when adding steering rule via ethtool. Fixes: 1174fce8 ('net/mlx5e: Support l3/l4 flow type specs in ethtool flow steering') Signed-off-by:
Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
-
Eli Cohen authored
[ Upstream commit d151d73d ] Avoid using a local variable named numa_node to avoid shadowing a public one. Fixes: db058a18 ('net/mlx5_core: Set irq affinity hints') Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
-
Daniel Jurgens authored
[ Upstream commit 689a248d ] If there is pending delayed work for health recovery it must be canceled if the device is being unloaded. Fixes: 05ac2c0b ("net/mlx5: Fix race between PCI error handlers and health work") Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
-
Noa Osherovich authored
[ Upstream commit 883371c4 ] When setting HCA capabilities, set log_max_qp to be the minimum between the selected profile's value and the HCA limitation. Fixes: 938fe83c ('net/mlx5_core: New device capabilities...') Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
-
Paul Blakey authored
[ Upstream commit 0df0f207 ] Since we now use a non zero mask on addr_type, we are matching on its value (IPV4/IPV6). So before this fix, matching on enc_src_ip/enc_dst_ip failed in SW/classify path since its value was zero. This patch sets the proper value of addr_type for encapsulated packets. Fixes: 970bfcd0 ('net/sched: cls_flower: Use mask for addr_type') Signed-off-by:
Paul Blakey <paulb@mellanox.com> Reviewed-by:
Hadar Hen Zion <hadarh@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 57016590 ] There is currently a small window during which the network device registered by stmmac can be made visible, yet all resources, including and clock and MDIO bus have not had a chance to be set up, this can lead to the following error to occur: [ 473.919358] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized): stmmac_dvr_probe: warning: cannot get CSR clock [ 473.919382] stmmaceth 0000:01:00.0: no reset control found [ 473.919412] stmmac - user ID: 0x10, Synopsys ID: 0x42 [ 473.919429] stmmaceth 0000:01:00.0: DMA HW capability register supported [ 473.919436] stmmaceth 0000:01:00.0: RX Checksum Offload Engine supported [ 473.919443] stmmaceth 0000:01:00.0: TX Checksum insertion supported [ 473.919451] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer [ 473.921395] libphy: PHY stmmac-1:00 not found [ 473.921417] stmmaceth 0000:01:00.0 eth0: Could not attach to PHY [ 473.921427] stmmaceth 0000:01:00.0 eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 473.959710] libphy: stmmac: probed [ 473.959724] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 0 IRQ POLL (stmmac-1:00) active [ 473.959728] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 1 IRQ POLL (stmmac-1:01) [ 473.959731] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 2 IRQ POLL (stmmac-1:02) [ 473.959734] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 3 IRQ POLL (stmmac-1:03) Fix this by making sure that register_netdev() is the last thing being done, which guarantees that the clock and the MDIO bus are available. Fixes: 4bfcbd7a ("stmmac: Move the mdio_register/_unregister in probe/remove") Reported-by:
Kweh, Hock Leong <hock.leong.kweh@intel.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 628185cf ] Shahar reported a soft lockup in tc_classify(), where we run into an endless loop when walking the classifier chain due to tp->next == tp which is a state we should never run into. The issue only seems to trigger under load in the tc control path. What happens is that in tc_ctl_tfilter(), thread A allocates a new tp, initializes it, sets tp_created to 1, and calls into tp->ops->change() with it. In that classifier callback we had to unlock/lock the rtnl mutex and returned with -EAGAIN. One reason why we need to drop there is, for example, that we need to request an action module to be loaded. This happens via tcf_exts_validate() -> tcf_action_init/_1() meaning after we loaded and found the requested action, we need to redo the whole request so we don't race against others. While we had to unlock rtnl in that time, thread B's request was processed next on that CPU. Thread B added a new tp instance successfully to the classifier chain. When thread A returned grabbing the rtnl mutex again, propagating -EAGAIN and destroying its tp instance which never got linked, we goto replay and redo A's request. This time when walking the classifier chain in tc_ctl_tfilter() for checking for existing tp instances we had a priority match and found the tp instance that was created and linked by thread B. Now calling again into tp->ops->change() with that tp was successful and returned without error. tp_created was never cleared in the second round, thus kernel thinks that we need to link it into the classifier chain (once again). tp and *back point to the same object due to the match we had earlier on. Thus for thread B's already public tp, we reset tp->next to tp itself and link it into the chain, which eventually causes the mentioned endless loop in tc_classify() once a packet hits the data path. Fix is to clear tp_created at the beginning of each request, also when we replay it. On the paths that can cause -EAGAIN we already destroy the original tp instance we had and on replay we really need to start from scratch. It seems that this issue was first introduced in commit 12186be7 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup"). Fixes: 12186be7 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup") Reported-by:
Shahar Klein <shahark@mellanox.com> Signed-off-by:
-
Dave Jones authored
[ Upstream commit a98f9175 ] By setting certain socket options on ipv6 raw sockets, we can confuse the length calculation in rawv6_push_pending_frames triggering a BUG_ON. RIP: 0010:[<ffffffff817c6390>] [<ffffffff817c6390>] rawv6_sendmsg+0xc30/0xc40 RSP: 0018:ffff881f6c4a7c18 EFLAGS: 00010282 RAX: 00000000fffffff2 RBX: ffff881f6c681680 RCX: 0000000000000002 RDX: ffff881f6c4a7cf8 RSI: 0000000000000030 RDI: ffff881fed0f6a00 RBP: ffff881f6c4a7da8 R08: 0000000000000000 R09: 0000000000000009 R10: ffff881fed0f6a00 R11: 0000000000000009 R12: 0000000000000030 R13: ffff881fed0f6a00 R14: ffff881fee39ba00 R15: ffff881fefa93a80 Call Trace: [<ffffffff8118ba23>] ? unmap_page_range+0x693/0x830 [<ffffffff81772697>] inet_sendmsg+0x67/0xa0 [<ffffffff816d93f8>] sock_sendmsg+0x38/0x50 [<ffffffff816d982f>] SYSC_sendto+0xef/0x170 [<ffffffff816da27e>] SyS_sendto+0xe/0x10 [<ffffffff81002910>] do_syscall_64+0x50/0xa0 [<ffffffff817f7cbc>] entry_SYSCALL64_slow_path+0x25/0x25 Handle by jumping to the failure path if skb_copy_bits gets an EFAULT. Reproducer: #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #define LEN 504 int main(int argc, char* argv[]) { int fd; int zero = 0; char buf[LEN]; memset(buf, 0, LEN); fd = socket(AF_INET6, SOCK_RAW, 7); setsockopt(fd, SOL_IPV6, IPV6_CHECKSUM, &zero, 4); setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, &buf, LEN); sendto(fd, buf, 1, 0, (struct sockaddr *) buf, 110); } Signed-off-by:
Dave Jones <davej@codemonkey.org.uk> Signed-off-by:
-
Willem de Bruijn authored
[ Upstream commit 39b2dd76 ] Socket cmsg IP(V6)_RECVORIGDSTADDR checks that port range lies within the packet. For sockets that have transport headers pulled, transport offset can be negative. Use signed comparison to avoid overflow. Fixes: e6afc8ac ("udp: remove headers from UDP packets before queueing") Reported-by:
Nisar Jagabar <njagabar@cloudmark.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Xin Long authored
[ Upstream commit 08abb795 ] Prior to this patch, sctp_transport_lookup_process didn't rcu_read_unlock when it failed to find a transport by sctp_addrs_lookup_transport. This patch is to fix it by moving up rcu_read_unlock right before checking transport and also to remove the out path. Fixes: 1cceda78 ("sctp: fix the issue sctp_diag uses lock_sock in rcu_read_lock") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
David Ahern authored
[ Upstream commit eb63ecc1 ] Locally originated traffic in a VRF fails in the presence of a POSTROUTING rule. For example, $ iptables -t nat -A POSTROUTING -s 11.1.1.0/24 -j MASQUERADE $ ping -I red -c1 11.1.1.3 ping: Warning: source address might be selected on device other than red. PING 11.1.1.3 (11.1.1.3) from 11.1.1.2 red: 56(84) bytes of data. ping: sendmsg: Operation not permitted Worse, the above causes random corruption resulting in a panic in random places (I have not seen a consistent backtrace). Call nf_reset to drop the conntrack info following the pass through the VRF device. The nf_reset is needed on Tx but not Rx because of the order in which NF_HOOK's are hit: on Rx the VRF device is after the real ingress device and on Tx it is is before the real egress device. Connection tracking should be tied to the real egress device and not the VRF device. Fixes: 8f58336d ("net: Add ethernet header for pass through VRF device") Fixes: 35402e31 ("net: Add IPv6 support to VRF device") Signed-off-by:
-
David Ahern authored
[ Upstream commit a0f37efa ] Connection tracking with VRF is broken because the pass through the VRF device drops the connection tracking info. Removing the call to nf_reset allows DNAT and MASQUERADE to work across interfaces within a VRF. Fixes: 73e20b76 ("net: vrf: Add support for PREROUTING rules on vrf device") Signed-off-by:
-
- 12 Jan, 2017 2 commits
-
-
Greg Kroah-Hartman authored
-
Felipe Balbi authored
commit eaa496ff upstream. ep->mult is supposed to be set to Isochronous and Interrupt Endapoint's multiplier value. This value is computed from different places depending on the link speed. If we're dealing with HighSpeed, then it's part of bits [12:11] of wMaxPacketSize. This case wasn't taken into consideration before. While at that, also make sure the ep->mult defaults to one so drivers can use it unconditionally and assume they'll never multiply ep->maxpacket to zero. Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
