- 13 Oct, 2013 40 commits
-
-
Dan Carpenter authored
commit d63733ae upstream. If the user passes an invalid value it leads to an info leak when we print the error message or it could oops. This is called with user supplied data from snd_ctl_elem_write(). Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
commit d967967e upstream. This is called from snd_ctl_elem_write() with user supplied data so we need to add some bounds checking. Signed-off-by:
-
Dan Carpenter authored
commit f8d7b13e upstream. The ->put() function are called from snd_ctl_elem_write() with user supplied data. The limit checks here could underflow leading to a crash. Signed-off-by:
-
Javier Martinez Canillas authored
commit fac7fa16 upstream. The OMAP GPIO controller HW requires a pin to be configured in GPIO input mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq(), and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Since this bypasses the GPIO subsystem we have to ensure that another driver won't be able to request the same GPIO pin that is used as an IRQ and set its direction as output. Requesting the GPIO and setting its direction as input is allowed though. This fixes smsc911x ethernet support for tobi and igep OMAP3 boards and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line. Acked-by:
Stephen Warren <swarren@nvidia.com> Tested-by:
George Cherian <george.cherian@ti.com> Tested-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Tested-by:
Lars Poeschel <poeschel@lemonage.de> Reviewed-by:
Kevin Hilman <khilman@linaro.org> Tested-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Javier Martinez Canillas authored
commit fa365e4d upstream. The GPIO OMAP controller pins can be used as IRQ and GPIO independently so is necessary to keep track GPIO pins and IRQ lines usage separately to make sure that the bank will always be enabled while being used. Also move gpio_is_input() definition in preparation for the next patch that setups the controller's irq_chip driver when a caller requests an interrupt line. Acked-by:
-
Dan Aloni authored
commit 72023656 upstream. A high setting of max_map_count, and a process core-dumping with a large enough vm_map_count could result in an NT_FILE note not being written, and the kernel crashing immediately later because it has assumed otherwise. Reproduction of the oops-causing bug described here: https://lkml.org/lkml/2013/8/30/50 Rge ussue originated in commit 2aa362c4 ("coredump: extend core dump note section to contain file names of mapped file") from Oct 4, 2012. This patch make that section optional in that case. fill_files_note() should signify the error, and also let the info struct in elf_core_dump() be zero-initialized so that we can check for the optionally written note. [akpm@linux-foundation.org: avoid abusing E2BIG, remove a couple of not-really-needed local variables] [akpm@linux-foundation.org: fix sparse warning] Signed-off-by:
Dan Aloni <alonid@stratoscale.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Denys Vlasenko <vda.linux@googlemail.com> Reported-by:
Martin MOKREJS <mmokrejs@gmail.com> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Gabor Juhos authored
commit 1b0135b5 upstream. Since commit 01426478 (avr32: Use generic idle loop) the kernel throws the following warning on avr32: WARNING: at 900322e4 [verbose debug info unavailable] Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0-rc2 #117 task: 901c3ecc ti: 901c0000 task.ti: 901c0000 PC is at cpu_idle_poll_ctrl+0x1c/0x38 LR is at comparator_mode+0x3e/0x40 pc : [<900322e4>] lr : [<90014882>] Not tainted sp : 901c1f74 r12: 00000000 r11: 901c74a0 r10: 901d2510 r9 : 00000001 r8 : 901db4de r7 : 901c74a0 r6 : 00000001 r5 : 00410020 r4 : 901db574 r3 : 00410024 r2 : 90206fe0 r1 : 00000000 r0 : 007f0000 Flags: qvnzc Mode bits: hjmde....G CPU Mode: Supervisor Call trace: [<90039ede>] clockevents_set_mode+0x16/0x2e [<90039f00>] clockevents_shutdown+0xa/0x1e [<9003a078>] clockevents_exchange_device+0x58/0x70 [<9003a78c>] tick_check_new_device+0x38/0x54 [<9003a1a2>] clockevents_register_device+0x32/0x90 [<900035c4>] time_init+0xa8/0x108 [<90000520>] start_kernel+0x128/0x23c When the 'avr32_comparator' clockevent device is registered, the clockevent core sets the mode of that clockevent device to CLOCK_EVT_MODE_SHUTDOWN. Due to this, the 'comparator_mode' function calls the 'cpu_idle_poll_ctrl' to disables idle poll. This results in the aforementioned warning because the polling is not enabled yet. Change the code to only disable idle poll if it is enabled by the same function to avoid the warning. Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Acked-by:
Hans-Christian Egtvedt <egtvedt@samfundet.no> Signed-off-by:
-
Nicolas Dichtel authored
[ Upstream commit bb814094 ] rtnl ops where introduced by c075b130 ("ip6tnl: advertise tunnel param via rtnl"), but I forget to assign rtnl ops to fb tunnels. Now that it is done, we must remove the explicit call to unregister_netdevice_queue(), because the fallback tunnel is added to the queue in ip6_tnl_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this is valid since commit 0bd87628 ("ip6tnl: add x-netns support")). Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Nicolas Dichtel authored
[ Upstream commit 205983c4 ] rtnl ops where introduced by ba3e3f50 ("sit: advertise tunnel param via rtnl"), but I forget to assign rtnl ops to fb tunnels. Now that it is done, we must remove the explicit call to unregister_netdevice_queue(), because the fallback tunnel is added to the queue in sit_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this is valid since commit 5e6700b3 ("sit: add support of x-netns")). Signed-off-by:
-
Steffen Klassert authored
[ Upstream commit 3e08f4a7 ] We might extend the used aera of a skb beyond the total headroom when we install the ipip header. Fix this by calling skb_cow_head() unconditionally. Bug was introduced with commit c5441932 ("GRE: Refactor GRE tunneling code.") Cc: Pravin Shelar <pshelar@nicira.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Ricardo Ribalda authored
[ Upstream commit 7167cf0e ] The dma descriptors indexes are only initialized on the probe function. If a packet is on the buffer when temac_stop is called, the dma descriptors indexes can be left on a incorrect state where no other package can be sent. So an interface could be left in an usable state after ifdow/ifup. This patch makes sure that the descriptors indexes are in a proper status when the device is open. Signed-off-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by:
-
Salam Noureddine authored
[ Upstream commit 9260d3e1 ] It is possible for the timer handlers to run after the call to ipv6_mc_down so use in6_dev_put instead of __in6_dev_put in the handler function in order to do proper cleanup when the refcnt reaches 0. Otherwise, the refcnt can reach zero without the inet6_dev being destroyed and we end up leaking a reference to the net_device and see messages like the following, unregister_netdevice: waiting for eth0 to become free. Usage count = 1 Tested on linux-3.4.43. Signed-off-by:
Salam Noureddine <noureddine@aristanetworks.com> Signed-off-by:
-
Salam Noureddine authored
[ Upstream commit e2401654 ] It is possible for the timer handlers to run after the call to ip_mc_down so use in_dev_put instead of __in_dev_put in the handler function in order to do proper cleanup when the refcnt reaches 0. Otherwise, the refcnt can reach zero without the in_device being destroyed and we end up leaking a reference to the net_device and see messages like the following, unregister_netdevice: waiting for eth0 to become free. Usage count = 1 Tested on linux-3.4.43. Signed-off-by:
-
Hannes Frederic Sowa authored
[ Upstream commit 3da812d8 ] gre_hlen already accounts for sizeof(struct ipv6_hdr) + gre header, so initialize max_headroom to zero. Otherwise the if (encap_limit >= 0) { max_headroom += 8; mtu -= 8; } increments an uninitialized variable before max_headroom was reset. Found with coverity: 728539 Cc: Dmitry Kozlov <xeb@mail.ru> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Neil Horman authored
[ Upstream commit 5a0068de ] Recently grabbed this report: https://bugzilla.redhat.com/show_bug.cgi?id=1005567 Of an issue in which the bonding driver, with an attached vlan encountered the following errors when bond0 was taken down and back up: dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of device might be broken. The error occurs because, during __bond_release_one, if we release our last slave, we take on a random mac address and issue a NETDEV_CHANGEADDR notification. With an attached vlan, the vlan may see that the vlan and bond mac address were in sync, but no longer are. This triggers a call to dev_uc_add and dev_set_rx_mode, which enables IFF_PROMISC on the bond device. Then, when we complete __bond_release_one, we use the current state of the bond flags to determine if we should decrement the promiscuity of the releasing slave. But since the bond changed promiscuity state during the release operation, we incorrectly decrement the slave promisc count when it wasn't in promiscuous mode to begin with, causing the above error Fix is pretty simple, just cache the bonding flags at the start of the function and use those when determining the need to set promiscuity. This is also needed for the ALLMULTI flag Reported-by:
Mark Wu <wudxw@linux.vnet.ibm.com> CC: Jay Vosburgh <fubar@us.ibm.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: Mark Wu <wudxw@linux.vnet.ibm.com> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Peter Korsgaard authored
[ Upstream commit bf0ea638 ] Pass-all-multicast is controlled by bit 3 in RX control, not bit 2 (pass undersized frames). Reported-by:
Joseph Chang <joseph_chang@davicom.com.tw> Signed-off-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 9a3bab6b ] A host might need net_secret[] and never open a single socket. Problem added in commit aebda156 ("net: defer net_secret[] initialization") Based on prior patch from Hannes Frederic Sowa. Reported-by:
Hannes Frederic Sowa <hannes@strressinduktion.org> Signed-off-by:
-
Catalin(ux) M. BOIE authored
[ Upstream commit 7df37ff3 ] When a router is doing DNAT for 6to4/6rd packets the latest anti-spoofing commit 218774dc ("ipv6: add anti-spoofing checks for 6to4 and 6rd") will drop them because the IPv6 address embedded does not match the IPv4 destination. This patch will allow them to pass by testing if we have an address that matches on 6to4/6rd interface. I have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR. Also, log the dropped packets (with rate limit). Signed-off-by:
Catalin(ux) M. BOIE <catab@embedromix.ro> Acked-by:
-
Roger Luethi authored
[ Upstream commit 207070f5 ] Outgoing packets sent by via-rhine have their VLAN PCP field off by one (when hardware acceleration is enabled). The TX descriptor expects only VID and PCP (without a CFI/DEI bit). Peter Boström noticed and reported the bug. Signed-off-by:
Roger Luethi <rl@hellgate.ch> Cc: Peter Boström <peter.bostrom@netrounds.com> Signed-off-by:
-
Hannes Frederic Sowa authored
[ Upstream commit 2811ebac ] In the following scenario the socket is corked: If the first UDP packet is larger then the mtu we try to append it to the write queue via ip6_ufo_append_data. A following packet, which is smaller than the mtu would be appended to the already queued up gso-skb via plain ip6_append_data. This causes random memory corruptions. In ip6_ufo_append_data we also have to be careful to not queue up the same skb multiple times. So setup the gso frame only when no first skb is available. This also fixes a shortcoming where we add the current packet's length to cork->length but return early because of a packet > mtu with dontfrag set (instead of sutracting it again). Found with trinity. Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Ansis Atteka authored
[ Upstream commit 703133de ] If local fragmentation is allowed, then ip_select_ident() and ip_select_ident_more() need to generate unique IDs to ensure correct defragmentation on the peer. For example, if IPsec (tunnel mode) has to encrypt large skbs that have local_df bit set, then all IP fragments that belonged to different ESP datagrams would have used the same identificator. If one of these IP fragments would get lost or reordered, then peer could possibly stitch together wrong IP fragments that did not belong to the same datagram. This would lead to a packet loss or data corruption. Signed-off-by:
Ansis Atteka <aatteka@nicira.com> Signed-off-by:
-
Ansis Atteka authored
[ Upstream commit 749154aa ] skb->data already points to IP header, but for the sake of consistency we can also use ip_hdr() to retrieve it. Signed-off-by:
-
Duan Jiong authored
[ Upstream commit bd784a14 ] DCCP shouldn't be setting sk_err on redirects as it isn't an error condition. it should be doing exactly what tcp is doing and leaving the error handler without touching the socket. Signed-off-by:
Duan Jiong <duanj.fnst@cn.fujitsu.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 3f96a532 ] Adapt the same behaviour for SCTP as present in TCP for ICMP redirect messages. For IPv6, RFC4443, section 2.4. says: ... (e) An ICMPv6 error message MUST NOT be originated as a result of receiving the following: ... (e.2) An ICMPv6 redirect message [IPv6-DISC]. ... Therefore, do not report an error to user space, just invoke dst's redirect callback and leave, same for IPv4 as done in TCP as well. The implication w/o having this patch could be that the reception of such packets would generate a poll notification and in worst case it could even tear down the whole connection. Therefore, stop updating sk_err on redirects. Reported-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Ding Zhi authored
[ Upstream commit 0d2ede92 ] IFLA_IPTUN_LOCAL and IFLA_IPTUN_REMOTE were inverted. Introduced by c075b130 (ip6tnl: advertise tunnel param via rtnl). Signed-off-by:
Ding Zhi <zhi.ding@6wind.com> Signed-off-by:
-
Hong Zhiguo authored
[ Upstream commit 716ec052 ] The NULL deref happens when br_handle_frame is called between these 2 lines of del_nbp: dev->priv_flags &= ~IFF_BRIDGE_PORT; /* --> br_handle_frame is called at this time */ netdev_rx_handler_unregister(dev); In br_handle_frame the return of br_port_get_rcu(dev) is dereferenced without check but br_port_get_rcu(dev) returns NULL if: !(dev->priv_flags & IFF_BRIDGE_PORT) Eric Dumazet pointed out the testing of IFF_BRIDGE_PORT is not necessary here since we're in rcu_read_lock and we have synchronize_net() in netdev_rx_handler_unregister. So remove the testing of IFF_BRIDGE_PORT and by the previous patch, make sure br_port_get_rcu is called in bridging code. Signed-off-by:
Hong Zhiguo <zhiguohong@tencent.com> Acked-by:
-
Hong Zhiguo authored
[ Upstream commit 1fb1754a ] current br_port_get_rcu is problematic in bridging path (NULL deref). Change these calls in netlink path first. Signed-off-by:
-
Herbert Xu authored
[ Upstream commit be4f154d ] At some point limits were added to forward_delay. However, the limits are only enforced when STP is enabled. This created a scenario where you could have a value outside the allowed range while STP is disabled, which then stuck around even after STP is enabled. This patch fixes this by clamping the value when we enable STP. I had to move the locking around a bit to ensure that there is no window where someone could insert a value outside the range while we're in the middle of enabling STP. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Chris Healy authored
[ Upstream commit 9a062013 ] This changes the message_age_timer calculation to use the BPDU's max age as opposed to the local bridge's max age. This is in accordance with section 8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification. With the current implementation, when running with very large bridge diameters, convergance will not always occur even if a root bridge is configured to have a longer max age. Tested successfully on bridge diameters of ~200. Signed-off-by:
Chris Healy <cphealy@gmail.com> Signed-off-by:
-
David Vrabel authored
[ Upstream commit 6e43fc04 ] When a VM is providing an iSCSI target and the LUN is used by the backend domain, the generated skbs for direct I/O writes to the disk have large, multi-page skb->data but no frags. With some lengths and starting offsets, xen_netbk_count_skb_slots() would be one short because the simple calculation of DIV_ROUND_UP(skb_headlen(), PAGE_SIZE) was not accounting for the decisions made by start_new_rx_buffer() which does not guarantee responses are fully packed. For example, a skb with length < 2 pages but which spans 3 pages would be counted as requiring 2 slots but would actually use 3 slots. skb->data: | 1111|222222222222|3333 | Fully packed, this would need 2 slots: |111122222222|22223333 | But because the 2nd page wholy fits into a slot it is not split across slots and goes into a slot of its own: |1111 |222222222222|3333 | Miscounting the number of slots means netback may push more responses than the number of available requests. This will cause the frontend to get very confused and report "Too many frags/slots". The frontend never recovers and will eventually BUG. Fix this by counting the number of required slots more carefully. In xen_netbk_count_skb_slots(), more closely follow the algorithm used by xen_netbk_gop_skb() by introducing xen_netbk_count_frag_slots() which is the dry-run equivalent of netbk_gop_frag_copy(). Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 95ee6208 ] Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport does not seem to have the desired effect: SCTP + IPv4: 22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116) 192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72 22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340) 192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1): SCTP + IPv6: 22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364) fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp 1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10] Moreover, Alan says: This problem was seen with both Racoon and Racoon2. Other people have seen this with OpenSwan. When IPsec is configured to encrypt all upper layer protocols the SCTP connection does not initialize. After using Wireshark to follow packets, this is because the SCTP packet leaves Box A unencrypted and Box B believes all upper layer protocols are to be encrypted so it drops this packet, causing the SCTP connection to fail to initialize. When IPsec is configured to encrypt just SCTP, the SCTP packets are observed unencrypted. In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext" string on the other end, results in cleartext on the wire where SCTP eventually does not report any errors, thus in the latter case that Alan reports, the non-paranoid user might think he's communicating over an encrypted transport on SCTP although he's not (tcpdump ... -X): ... 0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000 ]p.......}.l.... 0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000 ....plaintext... Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the receiver side. Initial follow-up analysis from Alan's bug report was done by Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this. SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit(). This has the implication that it probably never really got updated along with changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers. SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since a call to inet6_csk_xmit() would solve this problem, but result in unecessary route lookups, let us just use the cached flowi6 instead that we got through sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(), we do the route lookup / flow caching in sctp_transport_route(), hold it in tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst() instead to get the correct source routed dst entry, which we assign to the skb. Also source address routing example from 62503411 ("sctp: fix sctp to work with ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095 it is actually 'recommended' to not use that anyway due to traffic amplification [1]. So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if we overwrite the flow destination here, the lower IPv6 layer will be unable to put the correct destination address into IP header, as routing header is added in ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside, result of this patch is that we do not have any XfrmInTmplMismatch increase plus on the wire with this patch it now looks like: SCTP + IPv6: 08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba: AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72 08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a: AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296 This fixes Kernel Bugzilla 24412. This security issue seems to be present since 2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have its fun with that. lksctp-tools IPv6 regression test suite passes as well with this patch. [1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdfReported-by:
Alan Chester <alan.chester@tekelec.com> Reported-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Jason Wang authored
[ Upstream commit 662ca437 ] Commit c8d68e6b (tuntap: multiqueue support) only call free_netdev() on error in tun_set_iff(). This causes several issues: - memory of tun security were leaked - use after free since the flow gc timer was not deleted and the tfile were not detached This patch solves the above issues. Reported-by:
Wannes Rombouts <wannes.rombouts@epitech.eu> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Nikolay Aleksandrov authored
[ Upstream commit d0fe8c88 ] I've been hitting a NULL ptr deref while using netconsole because the np->dev check and the pointer manipulation in netpoll_cleanup are done without rtnl and the following sequence happens when having a netconsole over a vlan and we remove the vlan while disabling the netconsole: CPU 1 CPU2 removes vlan and calls the notifier enters store_enabled(), calls netdev_cleanup which checks np->dev and then waits for rtnl executes the netconsole netdev release notifier making np->dev == NULL and releases rtnl continues to dereference a member of np->dev which at this point is == NULL Signed-off-by:
Nikolay Aleksandrov <nikolay@redhat.com> Signed-off-by:
-
Sonic Zhang authored
[ Upstream commit b0dd663b ] The received ARP request type in the Ethernet packet head is ETH_P_ARP other than ETH_P_IP. [ Bug introduced by commit b7394d24 ("netpoll: prepare for ipv6") ] Signed-off-by:
Sonic Zhang <sonic.zhang@analog.com> Signed-off-by:
-
Francois Romieu authored
[ Upstream commit 3ced8c95 ] Same narrative as eb2dc35d ("r8169: RxConfig hack for the 8168evl.") regarding AMD IOMMU errors. RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the same. Tested-by:
David R <david@unsolicited.net> Tested-by:
Frédéric Leroy <fredo@starox.org> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Vimalkumar authored
[ Upstream commit f3ad857e ] Fix a typo added in commit 56b765b7 ("htb: improved accuracy at high rates") cbuffer should not be a copy of buffer. Signed-off-by:
Vimalkumar <j.vimal@gmail.com> Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit b8678358 ] In commit 8ed78166 ("flow_keys: include thoff into flow_keys for later usage"), we missed that existing code was using nhoff as a temporary variable that could not always contain transport header offset. This is not a problem for TCP/UDP because port offset (@poff) is 0 for these protocols. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 50d1784e ] commit 416186fb ("net: Split core bits of netdev_pick_tx into __netdev_pick_tx") added a bug that disables caching of queue index in the socket. This is the source of packet reorders for TCP flows, and again this is happening more often when using FQ pacing. Old code was doing if (queue_index != old_index) sk_tx_queue_set(sk, queue_index); Alexander renamed the variables but forgot to change sk_tx_queue_set() 2nd parameter. if (queue_index != new_index) sk_tx_queue_set(sk, queue_index); This means we store -1 over and over in sk->sk_tx_queue_mapping Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 88362ad8 ] This was originally reported in [1] and posted by Neil Horman [2], he said: Fix up a missed null pointer check in the asconf code. If we don't find a local address, but we pass in an address length of more than 1, we may dereference a NULL laddr pointer. Currently this can't happen, as the only users of the function pass in the value 1 as the addrcnt parameter, but its not hot path, and it doesn't hurt to check for NULL should that ever be the case. The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1 while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR so that we do *not* find a single address in the association's bind address list that is not in the packed array of addresses. If this happens when we have an established association with ASCONF-capable peers, then we could get a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1 and call later sctp_make_asconf_update_ip() with NULL laddr. BUT: this actually won't happen as sctp_bindx_rem() will catch such a case and return with an error earlier. As this is incredably unintuitive and error prone, add a check to catch at least future bugs here. As Neil says, its not hot path. Introduced by 8a07eb0a ("sctp: Add ASCONF operation on the single-homed host"). [1] http://www.spinics.net/lists/linux-sctp/msg02132.html [2] http://www.spinics.net/lists/linux-sctp/msg02133.htmlReported-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit a0fb05d1 ] If we do not add braces around ... mask |= POLLERR | sock_flag(sk, SOCK_SELECT_ERR_QUEUE) ? POLLPRI : 0; ... then this condition always evaluates to true as POLLERR is defined as 8 and binary or'd with whatever result comes out of sock_flag(). Hence instead of (X | Y) ? A : B, transform it into X | (Y ? A : B). Unfortunatelty, commit 8facd5fb ("net: fix smatch warnings inside datagram_poll") forgot about SCTP. :-( Introduced by 7d4c04fc ("net: add option to enable error queue packets waking select"). Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
