Skip to content
  1. Jul 28, 2019
    • Marcelo Ricardo Leitner's avatar
      sctp: fix error handling on stream scheduler initialization · d9ee5afd
      Marcelo Ricardo Leitner authored
      [ Upstream commit 4d141581 ]
      
      It allocates the extended area for outbound streams only on sendmsg
      calls, if they are not yet allocated.  When using the priority
      stream scheduler, this initialization may imply into a subsequent
      allocation, which may fail.  In this case, it was aborting the stream
      scheduler initialization but leaving the ->ext pointer (allocated) in
      there, thus in a partially initialized state.  On a subsequent call to
      sendmsg, it would notice the ->ext pointer in there, and trip on
      uninitialized stuff when trying to schedule the data chunk.
      
      The fix is undo the ->ext initialization if the stream scheduler
      initialization fails and avoid the partially initialized state.
      
      Although syzkaller bisected this to commit 4ff40b86
      
       ("sctp: set
      chunk transport correctly when it's a new asoc"), this bug was actually
      introduced on the commit I marked below.
      
      Reported-by: default avatar <syzbot+c1a380d42b190ad1e559@syzkaller.appspotmail.com>
      Fixes: 5bbbbe32
      
       ("sctp: introduce stream scheduler foundations")
      Tested-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9ee5afd
    • David Howells's avatar
      rxrpc: Fix send on a connected, but unbound socket · bfa79135
      David Howells authored
      [ Upstream commit e835ada0 ]
      
      If sendmsg() or sendmmsg() is called on a connected socket that hasn't had
      bind() called on it, then an oops will occur when the kernel tries to
      connect the call because no local endpoint has been allocated.
      
      Fix this by implicitly binding the socket if it is in the
      RXRPC_CLIENT_UNBOUND state, just like it does for the RXRPC_UNBOUND state.
      
      Further, the state should be transitioned to RXRPC_CLIENT_BOUND after this
      to prevent further attempts to bind it.
      
      This can be tested with:
      
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <string.h>
      	#include <sys/socket.h>
      	#include <arpa/inet.h>
      	#include <linux/rxrpc.h>
      	static const unsigned char inet6_addr[16] = {
      		0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -1, -1, 0xac, 0x14, 0x14, 0xaa
      	};
      	int main(void)
      	{
      		struct sockaddr_rxrpc srx;
      		struct cmsghdr *cm;
      		struct msghdr msg;
      		unsigned char control[16];
      		int fd;
      		memset(&srx, 0, sizeof(srx));
      		srx.srx_family = 0x21;
      		srx.srx_service = 0;
      		srx.transport_type = AF_INET;
      		srx.transport_len = 0x1c;
      		srx.transport.sin6.sin6_family = AF_INET6;
      		srx.transport.sin6.sin6_port = htons(0x4e22);
      		srx.transport.sin6.sin6_flowinfo = htons(0x4e22);
      		srx.transport.sin6.sin6_scope_id = htons(0xaa3b);
      		memcpy(&srx.transport.sin6.sin6_addr, inet6_addr, 16);
      		cm = (struct cmsghdr *)control;
      		cm->cmsg_len	= CMSG_LEN(sizeof(unsigned long));
      		cm->cmsg_level	= SOL_RXRPC;
      		cm->cmsg_type	= RXRPC_USER_CALL_ID;
      		*(unsigned long *)CMSG_DATA(cm) = 0;
      		msg.msg_name = NULL;
      		msg.msg_namelen = 0;
      		msg.msg_iov = NULL;
      		msg.msg_iovlen = 0;
      		msg.msg_control = control;
      		msg.msg_controllen = cm->cmsg_len;
      		msg.msg_flags = 0;
      		fd = socket(AF_RXRPC, SOCK_DGRAM, AF_INET);
      		connect(fd, (struct sockaddr *)&srx, sizeof(srx));
      		sendmsg(fd, &msg, 0);
      		return 0;
      	}
      
      Leading to the following oops:
      
      	BUG: kernel NULL pointer dereference, address: 0000000000000018
      	#PF: supervisor read access in kernel mode
      	#PF: error_code(0x0000) - not-present page
      	...
      	RIP: 0010:rxrpc_connect_call+0x42/0xa01
      	...
      	Call Trace:
      	 ? mark_held_locks+0x47/0x59
      	 ? __local_bh_enable_ip+0xb6/0xba
      	 rxrpc_new_client_call+0x3b1/0x762
      	 ? rxrpc_do_sendmsg+0x3c0/0x92e
      	 rxrpc_do_sendmsg+0x3c0/0x92e
      	 rxrpc_sendmsg+0x16b/0x1b5
      	 sock_sendmsg+0x2d/0x39
      	 ___sys_sendmsg+0x1a4/0x22a
      	 ? release_sock+0x19/0x9e
      	 ? reacquire_held_locks+0x136/0x160
      	 ? release_sock+0x19/0x9e
      	 ? find_held_lock+0x2b/0x6e
      	 ? __lock_acquire+0x268/0xf73
      	 ? rxrpc_connect+0xdd/0xe4
      	 ? __local_bh_enable_ip+0xb6/0xba
      	 __sys_sendmsg+0x5e/0x94
      	 do_syscall_64+0x7d/0x1bf
      	 entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 2341e077
      
       ("rxrpc: Simplify connect() implementation and simplify sendmsg() op")
      Reported-by: default avatar <syzbot+7966f2a0b2c7da8939b4@syzkaller.appspotmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfa79135
    • Heiner Kallweit's avatar
      r8169: fix issue with confused RX unit after PHY power-down on RTL8411b · 3e4e6b71
      Heiner Kallweit authored
      [ Upstream commit fe4e8db0 ]
      
      On RTL8411b the RX unit gets confused if the PHY is powered-down.
      This was reported in [0] and confirmed by Realtek. Realtek provided
      a sequence to fix the RX unit after PHY wakeup.
      
      The issue itself seems to have been there longer, the Fixes tag
      refers to where the fix applies properly.
      
      [0] https://bugzilla.redhat.com/show_bug.cgi?id=1692075
      
      Fixes: a99790bf
      
       ("r8169: Reinstate ASPM Support")
      Tested-by: default avatarIonut Radu <ionut.radu@gmail.com>
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e4e6b71
    • Yang Wei's avatar
      nfc: fix potential illegal memory access · 97739e5c
      Yang Wei authored
      [ Upstream commit dd006fc4
      
       ]
      
      The frags_q is not properly initialized, it may result in illegal memory
      access when conn_info is NULL.
      The "goto free_exit" should be replaced by "goto exit".
      
      Signed-off-by: default avatarYang Wei <albin_yang@163.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97739e5c
    • Jose Abreu's avatar
      net: stmmac: Re-work the queue selection for TSO packets · f47f68cc
      Jose Abreu authored
      [ Upstream commit 4993e5b3 ]
      
      Ben Hutchings says:
      	"This is the wrong place to change the queue mapping.
      	stmmac_xmit() is called with a specific TX queue locked,
      	and accessing a different TX queue results in a data race
      	for all of that queue's state.
      
      	I think this commit should be reverted upstream and in all
      	stable branches.  Instead, the driver should implement the
      	ndo_select_queue operation and override the queue mapping there."
      
      Fixes: c5acdbee
      
       ("net: stmmac: Send TSO packets always from Queue 0")
      Suggested-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarJose Abreu <joabreu@synopsys.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f47f68cc
    • Andrew Lunn's avatar
      net: phy: sfp: hwmon: Fix scaling of RX power · 201d7d62
      Andrew Lunn authored
      [ Upstream commit 0cea0e11
      
       ]
      
      The RX power read from the SFP uses units of 0.1uW. This must be
      scaled to units of uW for HWMON. This requires a divide by 10, not the
      current 100.
      
      With this change in place, sensors(1) and ethtool -m agree:
      
      sff2-isa-0000
      Adapter: ISA adapter
      in0:          +3.23 V
      temp1:        +33.1 C
      power1:      270.00 uW
      power2:      200.00 uW
      curr1:        +0.01 A
      
              Laser output power                        : 0.2743 mW / -5.62 dBm
              Receiver signal average optical power     : 0.2014 mW / -6.96 dBm
      
      Reported-by: default avatar <chris.healy@zii.aero>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Fixes: 1323061a
      
       ("net: phy: sfp: Add HWMON support for module sensors")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      201d7d62
    • John Hurley's avatar
      net: openvswitch: fix csum updates for MPLS actions · c60bce64
      John Hurley authored
      [ Upstream commit 0e3183cd ]
      
      Skbs may have their checksum value populated by HW. If this is a checksum
      calculated over the entire packet then the CHECKSUM_COMPLETE field is
      marked. Changes to the data pointer on the skb throughout the network
      stack still try to maintain this complete csum value if it is required
      through functions such as skb_postpush_rcsum.
      
      The MPLS actions in Open vSwitch modify a CHECKSUM_COMPLETE value when
      changes are made to packet data without a push or a pull. This occurs when
      the ethertype of the MAC header is changed or when MPLS lse fields are
      modified.
      
      The modification is carried out using the csum_partial function to get the
      csum of a buffer and add it into the larger checksum. The buffer is an
      inversion of the data to be removed followed by the new data. Because the
      csum is calculated over 16 bits and these values align with 16 bits, the
      effect is the removal of the old value from the CHECKSUM_COMPLETE and
      addition of the new value.
      
      However, the csum fed into the function and the outcome of the
      calculation are also inverted. This would only make sense if it was the
      new value rather than the old that was inverted in the input buffer.
      
      Fix the issue by removing the bit inverts in the csum_partial calculation.
      
      The bug was verified and the fix tested by comparing the folded value of
      the updated CHECKSUM_COMPLETE value with the folded value of a full
      software checksum calculation (reset skb->csum to 0 and run
      skb_checksum_complete(skb)). Prior to the fix the outcomes differed but
      after they produce the same result.
      
      Fixes: 25cd9ba0 ("openvswitch: Add basic MPLS support to kernel")
      Fixes: bc7cc599
      
       ("openvswitch: update checksum in {push,pop}_mpls")
      Signed-off-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Acked-by: default avatarPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c60bce64
    • Lorenzo Bianconi's avatar
      net: neigh: fix multiple neigh timer scheduling · 257441a0
      Lorenzo Bianconi authored
      [ Upstream commit 071c3798
      
       ]
      
      Neigh timer can be scheduled multiple times from userspace adding
      multiple neigh entries and forcing the neigh timer scheduling passing
      NTF_USE in the netlink requests.
      This will result in a refcount leak and in the following dump stack:
      
      [   32.465295] NEIGH: BUG, double timer add, state is 8
      [   32.465308] CPU: 0 PID: 416 Comm: double_timer_ad Not tainted 5.2.0+ #65
      [   32.465311] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-2.fc30 04/01/2014
      [   32.465313] Call Trace:
      [   32.465318]  dump_stack+0x7c/0xc0
      [   32.465323]  __neigh_event_send+0x20c/0x880
      [   32.465326]  ? ___neigh_create+0x846/0xfb0
      [   32.465329]  ? neigh_lookup+0x2a9/0x410
      [   32.465332]  ? neightbl_fill_info.constprop.0+0x800/0x800
      [   32.465334]  neigh_add+0x4f8/0x5e0
      [   32.465337]  ? neigh_xmit+0x620/0x620
      [   32.465341]  ? find_held_lock+0x85/0xa0
      [   32.465345]  rtnetlink_rcv_msg+0x204/0x570
      [   32.465348]  ? rtnl_dellink+0x450/0x450
      [   32.465351]  ? mark_held_locks+0x90/0x90
      [   32.465354]  ? match_held_lock+0x1b/0x230
      [   32.465357]  netlink_rcv_skb+0xc4/0x1d0
      [   32.465360]  ? rtnl_dellink+0x450/0x450
      [   32.465363]  ? netlink_ack+0x420/0x420
      [   32.465366]  ? netlink_deliver_tap+0x115/0x560
      [   32.465369]  ? __alloc_skb+0xc9/0x2f0
      [   32.465372]  netlink_unicast+0x270/0x330
      [   32.465375]  ? netlink_attachskb+0x2f0/0x2f0
      [   32.465378]  netlink_sendmsg+0x34f/0x5a0
      [   32.465381]  ? netlink_unicast+0x330/0x330
      [   32.465385]  ? move_addr_to_kernel.part.0+0x20/0x20
      [   32.465388]  ? netlink_unicast+0x330/0x330
      [   32.465391]  sock_sendmsg+0x91/0xa0
      [   32.465394]  ___sys_sendmsg+0x407/0x480
      [   32.465397]  ? copy_msghdr_from_user+0x200/0x200
      [   32.465401]  ? _raw_spin_unlock_irqrestore+0x37/0x40
      [   32.465404]  ? lockdep_hardirqs_on+0x17d/0x250
      [   32.465407]  ? __wake_up_common_lock+0xcb/0x110
      [   32.465410]  ? __wake_up_common+0x230/0x230
      [   32.465413]  ? netlink_bind+0x3e1/0x490
      [   32.465416]  ? netlink_setsockopt+0x540/0x540
      [   32.465420]  ? __fget_light+0x9c/0xf0
      [   32.465423]  ? sockfd_lookup_light+0x8c/0xb0
      [   32.465426]  __sys_sendmsg+0xa5/0x110
      [   32.465429]  ? __ia32_sys_shutdown+0x30/0x30
      [   32.465432]  ? __fd_install+0xe1/0x2c0
      [   32.465435]  ? lockdep_hardirqs_off+0xb5/0x100
      [   32.465438]  ? mark_held_locks+0x24/0x90
      [   32.465441]  ? do_syscall_64+0xf/0x270
      [   32.465444]  do_syscall_64+0x63/0x270
      [   32.465448]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fix the issue unscheduling neigh_timer if selected entry is in 'IN_TIMER'
      receiving a netlink request with NTF_USE flag set
      
      Reported-by: default avatarMarek Majkowski <marek@cloudflare.com>
      Fixes: 0c5c2d30
      
       ("neigh: Allow for user space users of the neighbour table")
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      257441a0
    • Florian Westphal's avatar
      net: make skb_dst_force return true when dst is refcounted · 832d0ea7
      Florian Westphal authored
      [ Upstream commit b60a7738
      
       ]
      
      netfilter did not expect that skb_dst_force() can cause skb to lose its
      dst entry.
      
      I got a bug report with a skb->dst NULL dereference in netfilter
      output path.  The backtrace contains nf_reinject(), so the dst might have
      been cleared when skb got queued to userspace.
      
      Other users were fixed via
      if (skb_dst(skb)) {
      	skb_dst_force(skb);
      	if (!skb_dst(skb))
      		goto handle_err;
      }
      
      But I think its preferable to make the 'dst might be cleared' part
      of the function explicit.
      
      In netfilter case, skb with a null dst is expected when queueing in
      prerouting hook, so drop skb for the other hooks.
      
      v2:
       v1 of this patch returned true in case skb had no dst entry.
       Eric said:
         Say if we have two skb_dst_force() calls for some reason
         on the same skb, only the first one will return false.
      
       This now returns false even when skb had no dst, as per Erics
       suggestion, so callers might need to check skb_dst() first before
       skb_dst_force().
      
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      832d0ea7
    • Baruch Siach's avatar
      net: dsa: mv88e6xxx: wait after reset deactivation · 6ab30a4c
      Baruch Siach authored
      [ Upstream commit 7b75e49d
      
       ]
      
      Add a 1ms delay after reset deactivation. Otherwise the chip returns
      bogus ID value. This is observed with 88E6390 (Peridot) chip.
      
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ab30a4c
    • Justin Chen's avatar
      net: bcmgenet: use promisc for unsupported filters · 5832ef4a
      Justin Chen authored
      [ Upstream commit 35cbef98
      
       ]
      
      Currently we silently ignore filters if we cannot meet the filter
      requirements. This will lead to the MAC dropping packets that are
      expected to pass. A better solution would be to set the NIC to promisc
      mode when the required filters cannot be met.
      
      Also correct the number of MDF filters supported. It should be 17,
      not 16.
      
      Signed-off-by: default avatarJustin Chen <justinpopo6@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5832ef4a
    • Ido Schimmel's avatar
      ipv6: Unlink sibling route in case of failure · c0f4a644
      Ido Schimmel authored
      [ Upstream commit 54851aa9 ]
      
      When a route needs to be appended to an existing multipath route,
      fib6_add_rt2node() first appends it to the siblings list and increments
      the number of sibling routes on each sibling.
      
      Later, the function notifies the route via call_fib6_entry_notifiers().
      In case the notification is vetoed, the route is not unlinked from the
      siblings list, which can result in a use-after-free.
      
      Fix this by unlinking the route from the siblings list before returning
      an error.
      
      Audited the rest of the call sites from which the FIB notification chain
      is called and could not find more problems.
      
      Fixes: 2233000c
      
       ("net/ipv6: Move call_fib6_entry_notifiers up for route adds")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarAlexander Petrovskiy <alexpe@mellanox.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0f4a644
    • David Ahern's avatar
      ipv6: rt6_check should return NULL if 'from' is NULL · 0bd84505
      David Ahern authored
      [ Upstream commit 49d05fe2 ]
      
      Paul reported that l2tp sessions were broken after the commit referenced
      in the Fixes tag. Prior to this commit rt6_check returned NULL if the
      rt6_info 'from' was NULL - ie., the dst_entry was disconnected from a FIB
      entry. Restore that behavior.
      
      Fixes: 93531c67
      
       ("net/ipv6: separate handling of FIB entries from dst based routes")
      Reported-by: default avatarPaul Donohue <linux-kernel@PaulSD.com>
      Tested-by: default avatarPaul Donohue <linux-kernel@PaulSD.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0bd84505
    • Matteo Croce's avatar
      ipv4: don't set IPv6 only flags to IPv4 addresses · 47ce4427
      Matteo Croce authored
      [ Upstream commit 2e605463
      
       ]
      
      Avoid the situation where an IPV6 only flag is applied to an IPv4 address:
      
          # ip addr add 192.0.2.1/24 dev dummy0 nodad home mngtmpaddr noprefixroute
          # ip -4 addr show dev dummy0
          2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
              inet 192.0.2.1/24 scope global noprefixroute dummy0
                 valid_lft forever preferred_lft forever
      
      Or worse, by sending a malicious netlink command:
      
          # ip -4 addr show dev dummy0
          2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
              inet 192.0.2.1/24 scope global nodad optimistic dadfailed home tentative mngtmpaddr noprefixroute stable-privacy dummy0
                 valid_lft forever preferred_lft forever
      
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47ce4427
    • Eric Dumazet's avatar
      igmp: fix memory leak in igmpv3_del_delrec() · aee5dd00
      Eric Dumazet authored
      [ Upstream commit e5b1c6c6 ]
      
      im->tomb and/or im->sources might not be NULL, but we
      currently overwrite their values blindly.
      
      Using swap() will make sure the following call to kfree_pmc(pmc)
      will properly free the psf structures.
      
      Tested with the C repro provided by syzbot, which basically does :
      
       socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
       setsockopt(3, SOL_IP, IP_ADD_MEMBERSHIP, "\340\0\0\2\177\0\0\1\0\0\0\0", 12) = 0
       ioctl(3, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=0}) = 0
       setsockopt(3, SOL_IP, IP_MSFILTER, "\340\0\0\2\177\0\0\1\1\0\0\0\1\0\0\0\377\377\377\377", 20) = 0
       ioctl(3, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=IFF_UP}) = 0
       exit_group(0)                    = ?
      
      BUG: memory leak
      unreferenced object 0xffff88811450f140 (size 64):
        comm "softirq", pid 0, jiffies 4294942448 (age 32.070s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  ................
          00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000c7bad083>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
          [<00000000c7bad083>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<00000000c7bad083>] slab_alloc mm/slab.c:3326 [inline]
          [<00000000c7bad083>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
          [<000000009acc4151>] kmalloc include/linux/slab.h:547 [inline]
          [<000000009acc4151>] kzalloc include/linux/slab.h:742 [inline]
          [<000000009acc4151>] ip_mc_add1_src net/ipv4/igmp.c:1976 [inline]
          [<000000009acc4151>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2100
          [<000000004ac14566>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2484
          [<0000000052d8f995>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:959
          [<000000004ee1e21f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1248
          [<0000000066cdfe74>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2618
          [<000000009383a786>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3126
          [<00000000d8ac0c94>] __sys_setsockopt+0x98/0x120 net/socket.c:2072
          [<000000001b1e9666>] __do_sys_setsockopt net/socket.c:2083 [inline]
          [<000000001b1e9666>] __se_sys_setsockopt net/socket.c:2080 [inline]
          [<000000001b1e9666>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080
          [<00000000420d395e>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<000000007fd83a4b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 24803f38
      
       ("igmp: do not remove igmp souce list info when set link down")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Hangbin Liu <liuhangbin@gmail.com>
      Reported-by: default avatar <syzbot+6ca1abd0db68b5173a4f@syzkaller.appspotmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aee5dd00
    • Haiyang Zhang's avatar
      hv_netvsc: Fix extra rcu_read_unlock in netvsc_recv_callback() · 9770fe1b
      Haiyang Zhang authored
      [ Upstream commit be4363bd ]
      
      There is an extra rcu_read_unlock left in netvsc_recv_callback(),
      after a previous patch that removes RCU from this function.
      This patch removes the extra RCU unlock.
      
      Fixes: 345ac089
      
       ("hv_netvsc: pass netvsc_device to receive callback")
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9770fe1b
    • Taehee Yoo's avatar
      caif-hsi: fix possible deadlock in cfhsi_exit_module() · d7cdac6d
      Taehee Yoo authored
      [ Upstream commit fdd258d4 ]
      
      cfhsi_exit_module() calls unregister_netdev() under rtnl_lock().
      but unregister_netdev() internally calls rtnl_lock().
      So deadlock would occur.
      
      Fixes: c4125400
      
       ("caif-hsi: Add rtnl support")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7cdac6d
    • Brian King's avatar
      bnx2x: Prevent load reordering in tx completion processing · 8fb37be1
      Brian King authored
      [ Upstream commit ea811b79
      
       ]
      
      This patch fixes an issue seen on Power systems with bnx2x which results
      in the skb is NULL WARN_ON in bnx2x_free_tx_pkt firing due to the skb
      pointer getting loaded in bnx2x_free_tx_pkt prior to the hw_cons
      load in bnx2x_tx_int. Adding a read memory barrier resolves the issue.
      
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8fb37be1
  2. Jul 26, 2019