1. 27 11月, 2019 2 次提交
  2. 26 11月, 2019 6 次提交
    • J
      slip: Fix use-after-free Read in slip_open · e58c1912
      Jouni Hogander 提交于
      Slip_open doesn't clean-up device which registration failed from the
      slip_devs device list. On next open after failure this list is iterated
      and freed device is accessed. Fix this by calling sl_free_netdev in error
      path.
      
      Here is the trace from the Syzbot:
      
      __dump_stack lib/dump_stack.c:77 [inline]
      dump_stack+0x197/0x210 lib/dump_stack.c:118
      print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
      __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
      kasan_report+0x12/0x20 mm/kasan/common.c:634
      __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
      sl_sync drivers/net/slip/slip.c:725 [inline]
      slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801
      tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469
      tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596
      tiocsetd drivers/tty/tty_io.c:2334 [inline]
      tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594
      vfs_ioctl fs/ioctl.c:46 [inline]
      file_ioctl fs/ioctl.c:509 [inline]
      do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696
      ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
      __do_sys_ioctl fs/ioctl.c:720 [inline]
      __se_sys_ioctl fs/ioctl.c:718 [inline]
      __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
      do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 3b5a3997 ("slip: Fix memory leak in slip_open error path")
      Reported-by: syzbot+4d5170758f3762109542@syzkaller.appspotmail.com
      Cc: David Miller <davem@davemloft.net>
      Cc: Oliver Hartkopp <socketcan@hartkopp.net>
      Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
      Signed-off-by: NJouni Hogander <jouni.hogander@unikie.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e58c1912
    • O
      net: dsa: sja1105: fix sja1105_parse_rgmii_delays() · 9bca3a0a
      Oleksij Rempel 提交于
      This function was using configuration of port 0 in devicetree for all ports.
      In case CPU port was not 0, the delay settings was ignored. This resulted not
      working communication between CPU and the switch.
      
      Fixes: f5b8631c ("net: dsa: sja1105: Error out if RGMII delays are requested in DT")
      Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9bca3a0a
    • M
      macvlan: schedule bc_work even if error · 1d7ea556
      Menglong Dong 提交于
      While enqueueing a broadcast skb to port->bc_queue, schedule_work()
      is called to add port->bc_work, which processes the skbs in
      bc_queue, to "events" work queue. If port->bc_queue is full, the
      skb will be discarded and schedule_work(&port->bc_work) won't be
      called. However, if port->bc_queue is full and port->bc_work is not
      running or pending, port->bc_queue will keep full and schedule_work()
      won't be called any more, and all broadcast skbs to macvlan will be
      discarded. This case can happen:
      
      macvlan_process_broadcast() is the pending function of port->bc_work,
      it moves all the skbs in port->bc_queue to the queue "list", and
      processes the skbs in "list". During this, new skbs will keep being
      added to port->bc_queue in macvlan_broadcast_enqueue(), and
      port->bc_queue may already full when macvlan_process_broadcast()
      return. This may happen, especially when there are a lot of real-time
      threads and the process is preempted.
      
      Fix this by calling schedule_work(&port->bc_work) even if
      port->bc_work is full in macvlan_broadcast_enqueue().
      
      Fixes: 412ca155 ("macvlan: Move broadcasts into a work queue")
      Signed-off-by: NMenglong Dong <dong.menglong@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d7ea556
    • P
      enetc: add support Credit Based Shaper(CBS) for hardware offload · c431047c
      Po Liu 提交于
      The ENETC hardware support the Credit Based Shaper(CBS) which part
      of the IEEE-802.1Qav. The CBS driver was loaded by the sch_cbs
      interface when set in the QOS in the kernel.
      
      Here is an example command to set 20Mbits bandwidth in 1Gbits port
      for taffic class 7:
      
      tc qdisc add dev eth0 root handle 1: mqprio \
      	   num_tc 8 map 0 1 2 3 4 5 6 7 hw 1
      
      tc qdisc replace dev eth0 parent 1:8 cbs \
      	   locredit -1470 hicredit 30 \
      	   sendslope -980000 idleslope 20000 offload 1
      Signed-off-by: NPo Liu <Po.Liu@nxp.com>
      Reviewed-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
      Reviewed-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c431047c
    • H
      net: phy: add helpers phy_(un)lock_mdio_bus · bec170e5
      Heiner Kallweit 提交于
      Add helpers to make locking/unlocking the MDIO bus easier.
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bec170e5
    • D
      mdio_bus: don't use managed reset-controller · 32085f25
      David Bauer 提交于
      Geert Uytterhoeven reported that using devm_reset_controller_get leads
      to a WARNING when probing a reset-controlled PHY. This is because the
      device devm_reset_controller_get gets supplied is not actually the
      one being probed.
      
      Acquire an unmanaged reset-control as well as free the reset_control on
      unregister to fix this.
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      CC: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid Bauer <mail@david-bauer.net>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32085f25
  3. 25 11月, 2019 17 次提交
  4. 24 11月, 2019 5 次提交
  5. 23 11月, 2019 10 次提交