Skip to content
Snippets Groups Projects
  1. Dec 22, 2021
  2. Dec 21, 2021
  3. Dec 18, 2021
    • Jiasheng Jiang's avatar
      qlcnic: potential dereference null pointer of rx_queue->page_ring · 60ec7fcf
      Jiasheng Jiang authored
      
      The return value of kcalloc() needs to be checked.
      To avoid dereference of null pointer in case of the failure of alloc.
      Therefore, it might be better to change the return type of
      qlcnic_sriov_alloc_vlans() and return -ENOMEM when alloc fails and
      return 0 the others.
      Also, qlcnic_sriov_set_guest_vlan_mode() and __qlcnic_pci_sriov_enable()
      should deal with the return value of qlcnic_sriov_alloc_vlans().
      
      Fixes: 154d0c81 ("qlcnic: VLAN enhancement for 84XX adapters")
      Signed-off-by: default avatarJiasheng Jiang <jiasheng@iscas.ac.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60ec7fcf
    • Lin Ma's avatar
      hamradio: improve the incomplete fix to avoid NPD · b2f37aea
      Lin Ma authored
      
      The previous commit 3e0588c2 ("hamradio: defer ax25 kfree after
      unregister_netdev") reorder the kfree operations and unregister_netdev
      operation to prevent UAF.
      
      This commit improves the previous one by also deferring the nullify of
      the ax->tty pointer. Otherwise, a NULL pointer dereference bug occurs.
      Partial of the stack trace is shown below.
      
      BUG: kernel NULL pointer dereference, address: 0000000000000538
      RIP: 0010:ax_xmit+0x1f9/0x400
      ...
      Call Trace:
       dev_hard_start_xmit+0xec/0x320
       sch_direct_xmit+0xea/0x240
       __qdisc_run+0x166/0x5c0
       __dev_queue_xmit+0x2c7/0xaf0
       ax25_std_establish_data_link+0x59/0x60
       ax25_connect+0x3a0/0x500
       ? security_socket_connect+0x2b/0x40
       __sys_connect+0x96/0xc0
       ? __hrtimer_init+0xc0/0xc0
       ? common_nsleep+0x2e/0x50
       ? switch_fpu_return+0x139/0x1a0
       __x64_sys_connect+0x11/0x20
       do_syscall_64+0x33/0x40
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The crash point is shown as below
      
      static void ax_encaps(...) {
        ...
        set_bit(TTY_DO_WRITE_WAKEUP, &ax->tty->flags); // ax->tty = NULL!
        ...
      }
      
      By placing the nullify action after the unregister_netdev, the ax->tty
      pointer won't be assigned as NULL net_device framework layer is well
      synchronized.
      
      Signed-off-by: default avatarLin Ma <linma@zju.edu.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b2f37aea
    • George Kennedy's avatar
      tun: avoid double free in tun_free_netdev · 158b515f
      George Kennedy authored
      
      Avoid double free in tun_free_netdev() by moving the
      dev->tstats and tun->security allocs to a new ndo_init routine
      (tun_net_init()) that will be called by register_netdevice().
      ndo_init is paired with the desctructor (tun_free_netdev()),
      so if there's an error in register_netdevice() the destructor
      will handle the frees.
      
      BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
      
      CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1
      Hardware name: Red Hat KVM, BIOS
      Call Trace:
      <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
      print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247
      kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372
      ____kasan_slab_free mm/kasan/common.c:346 [inline]
      __kasan_slab_free+0x107/0x120 mm/kasan/common.c:374
      kasan_slab_free include/linux/kasan.h:235 [inline]
      slab_free_hook mm/slub.c:1723 [inline]
      slab_free_freelist_hook mm/slub.c:1749 [inline]
      slab_free mm/slub.c:3513 [inline]
      kfree+0xac/0x2d0 mm/slub.c:4561
      selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
      security_tun_dev_free_security+0x4f/0x90 security/security.c:2342
      tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215
      netdev_run_todo+0x4df/0x840 net/core/dev.c:10627
      rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112
      __tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302
      tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311
      vfs_ioctl fs/ioctl.c:51 [inline]
      __do_sys_ioctl fs/ioctl.c:874 [inline]
      __se_sys_ioctl fs/ioctl.c:860 [inline]
      __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Reported-by: default avatarsyzkaller <syzkaller@googlegroups.com>
      Signed-off-by: default avatarGeorge Kennedy <george.kennedy@oracle.com>
      Suggested-by: default avatarJakub Kicinski <kuba@kernel.org>
      Link: https://lore.kernel.org/r/1639679132-19884-1-git-send-email-george.kennedy@oracle.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      158b515f
    • Yevhen Orlov's avatar
      net: marvell: prestera: fix incorrect structure access · 2efc2256
      Yevhen Orlov authored
      
      In line:
      	upper = info->upper_dev;
      We access upper_dev field, which is related only for particular events
      (e.g. event == NETDEV_CHANGEUPPER). So, this line cause invalid memory
      access for another events,
      when ptr is not netdev_notifier_changeupper_info.
      
      The KASAN logs are as follows:
      
      [   30.123165] BUG: KASAN: stack-out-of-bounds in prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera]
      [   30.133336] Read of size 8 at addr ffff80000cf772b0 by task udevd/778
      [   30.139866]
      [   30.141398] CPU: 0 PID: 778 Comm: udevd Not tainted 5.16.0-rc3 #6
      [   30.147588] Hardware name: DNI AmazonGo1 A7040 board (DT)
      [   30.153056] Call trace:
      [   30.155547]  dump_backtrace+0x0/0x2c0
      [   30.159320]  show_stack+0x18/0x30
      [   30.162729]  dump_stack_lvl+0x68/0x84
      [   30.166491]  print_address_description.constprop.0+0x74/0x2b8
      [   30.172346]  kasan_report+0x1e8/0x250
      [   30.176102]  __asan_load8+0x98/0xe0
      [   30.179682]  prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera]
      [   30.186847]  prestera_netdev_event_handler+0x1b4/0x1c0 [prestera]
      [   30.193313]  raw_notifier_call_chain+0x74/0xa0
      [   30.197860]  call_netdevice_notifiers_info+0x68/0xc0
      [   30.202924]  register_netdevice+0x3cc/0x760
      [   30.207190]  register_netdev+0x24/0x50
      [   30.211015]  prestera_device_register+0x8a0/0xba0 [prestera]
      
      Fixes: 3d5048cc ("net: marvell: prestera: move netdev topology validation to prestera_main")
      Signed-off-by: default avatarYevhen Orlov <yevhen.orlov@plvision.eu>
      Link: https://lore.kernel.org/r/20211216171714.11341-1-yevhen.orlov@plvision.eu
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2efc2256
    • Yevhen Orlov's avatar
      net: marvell: prestera: fix incorrect return of port_find · 8b681bd7
      Yevhen Orlov authored
      
      In case, when some ports is in list and we don't find requested - we
      return last iterator state and not return NULL as expected.
      
      Fixes: 501ef306 ("net: marvell: prestera: Add driver for Prestera family ASIC devices")
      Signed-off-by: default avatarYevhen Orlov <yevhen.orlov@plvision.eu>
      Link: https://lore.kernel.org/r/20211216170736.8851-1-yevhen.orlov@plvision.eu
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8b681bd7
    • Aleksander Jan Bajkowski's avatar
      net: lantiq_xrx200: increase buffer reservation · 1488fc20
      Aleksander Jan Bajkowski authored
      
      If the user sets a lower mtu on the CPU port than on the switch,
      then DMA inserts a few more bytes into the buffer than expected.
      In the worst case, it may exceed the size of the buffer. The
      experiments showed that the buffer should be a multiple of the
      burst length value. This patch rounds the length of the rx buffer
      upwards and fixes this bug. The reservation of FCS space in the
      buffer has been removed as PMAC strips the FCS.
      
      Fixes: 998ac358 ("net: lantiq: add support for jumbo frames")
      Reported-by: default avatarThomas Nixon <tom@tomn.co.uk>
      Signed-off-by: default avatarAleksander Jan Bajkowski <olek2@wp.pl>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1488fc20
  4. Dec 17, 2021
  5. Dec 16, 2021
  6. Dec 15, 2021
    • Cyril Novikov's avatar
      ixgbe: set X550 MDIO speed before talking to PHY · bf0a3750
      Cyril Novikov authored
      
      The MDIO bus speed must be initialized before talking to the PHY the first
      time in order to avoid talking to it using a speed that the PHY doesn't
      support.
      
      This fixes HW initialization error -17 (IXGBE_ERR_PHY_ADDR_INVALID) on
      Denverton CPUs (a.k.a. the Atom C3000 family) on ports with a 10Gb network
      plugged in. On those devices, HLREG0[MDCSPD] resets to 1, which combined
      with the 10Gb network results in a 24MHz MDIO speed, which is apparently
      too fast for the connected PHY. PHY register reads over MDIO bus return
      garbage, leading to initialization failure.
      
      Reproduced with Linux kernel 4.19 and 5.15-rc7. Can be reproduced using
      the following setup:
      
      * Use an Atom C3000 family system with at least one X552 LAN on the SoC
      * Disable PXE or other BIOS network initialization if possible
        (the interface must not be initialized before Linux boots)
      * Connect a live 10Gb Ethernet cable to an X550 port
      * Power cycle (not reset, doesn't always work) the system and boot Linux
      * Observe: ixgbe interfaces w/ 10GbE cables plugged in fail with error -17
      
      Fixes: e84db727 ("ixgbe: Introduce function to control MDIO speed")
      Signed-off-by: default avatarCyril Novikov <cnovikov@lynx.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      bf0a3750
    • Robert Schlabbach's avatar
      ixgbe: Document how to enable NBASE-T support · 271225fd
      Robert Schlabbach authored
      Commit a296d665 ("ixgbe: Add ethtool support to enable 2.5 and 5.0
      Gbps support") introduced suppression of the advertisement of NBASE-T
      speeds by default, according to Todd Fujinaka to accommodate customers
      with network switches which could not cope with advertised NBASE-T
      speeds, as posted in the E1000-devel mailing list:
      
      https://sourceforge.net/p/e1000/mailman/message/37106269/
      
      
      
      However, the suppression was not documented at all, nor was how to
      enable NBASE-T support.
      
      Properly document the NBASE-T suppression and how to enable NBASE-T
      support.
      
      Fixes: a296d665 ("ixgbe: Add ethtool support to enable 2.5 and 5.0 Gbps support")
      Reported-by: default avatarRobert Schlabbach <robert_s@gmx.net>
      Signed-off-by: default avatarRobert Schlabbach <robert_s@gmx.net>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      271225fd
    • Sasha Neftin's avatar
      igc: Fix typo in i225 LTR functions · 0182d1f3
      Sasha Neftin authored
      
      The LTR maximum value was incorrectly written using the scale from
      the LTR minimum value. This would cause incorrect values to be sent,
      in cases where the initial calculation lead to different min/max scales.
      
      Fixes: 707abf06 ("igc: Add initial LTR support")
      Suggested-by: default avatarDima Ruinskiy <dima.ruinskiy@intel.com>
      Signed-off-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarNechama Kraus <nechamax.kraus@linux.intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      0182d1f3
    • Letu Ren's avatar
      igbvf: fix double free in `igbvf_probe` · b6d335a6
      Letu Ren authored
      
      In `igbvf_probe`, if register_netdev() fails, the program will go to
      label err_hw_init, and then to label err_ioremap. In free_netdev() which
      is just below label err_ioremap, there is `list_for_each_entry_safe` and
      `netif_napi_del` which aims to delete all entries in `dev->napi_list`.
      The program has added an entry `adapter->rx_ring->napi` which is added by
      `netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has
      been freed below label err_hw_init. So this a UAF.
      
      In terms of how to patch the problem, we can refer to igbvf_remove() and
      delete the entry before `adapter->rx_ring`.
      
      The KASAN logs are as follows:
      
      [   35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450
      [   35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366
      [   35.128360]
      [   35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14
      [   35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
      [   35.131749] Call Trace:
      [   35.132199]  dump_stack_lvl+0x59/0x7b
      [   35.132865]  print_address_description+0x7c/0x3b0
      [   35.133707]  ? free_netdev+0x1fd/0x450
      [   35.134378]  __kasan_report+0x160/0x1c0
      [   35.135063]  ? free_netdev+0x1fd/0x450
      [   35.135738]  kasan_report+0x4b/0x70
      [   35.136367]  free_netdev+0x1fd/0x450
      [   35.137006]  igbvf_probe+0x121d/0x1a10 [igbvf]
      [   35.137808]  ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]
      [   35.138751]  local_pci_probe+0x13c/0x1f0
      [   35.139461]  pci_device_probe+0x37e/0x6c0
      [   35.165526]
      [   35.165806] Allocated by task 366:
      [   35.166414]  ____kasan_kmalloc+0xc4/0xf0
      [   35.167117]  foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]
      [   35.168078]  igbvf_probe+0x9c5/0x1a10 [igbvf]
      [   35.168866]  local_pci_probe+0x13c/0x1f0
      [   35.169565]  pci_device_probe+0x37e/0x6c0
      [   35.179713]
      [   35.179993] Freed by task 366:
      [   35.180539]  kasan_set_track+0x4c/0x80
      [   35.181211]  kasan_set_free_info+0x1f/0x40
      [   35.181942]  ____kasan_slab_free+0x103/0x140
      [   35.182703]  kfree+0xe3/0x250
      [   35.183239]  igbvf_probe+0x1173/0x1a10 [igbvf]
      [   35.184040]  local_pci_probe+0x13c/0x1f0
      
      Fixes: d4e0fe01 (igbvf: add new driver to support 82576 virtual functions)
      Reported-by: default avatarZheyu Ma <zheyuma97@gmail.com>
      Signed-off-by: default avatarLetu Ren <fantasquex@gmail.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      b6d335a6
    • Karen Sornek's avatar
      igb: Fix removal of unicast MAC filters of VFs · 584af821
      Karen Sornek authored
      
      Move checking condition of VF MAC filter before clearing
      or adding MAC filter to VF to prevent potential blackout caused
      by removal of necessary and working VF's MAC filter.
      
      Fixes: 1b8b062a ("igb: add VF trust infrastructure")
      Signed-off-by: default avatarKaren Sornek <karen.sornek@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      584af821
  7. Dec 14, 2021
    • Karol Kolacinski's avatar
      ice: Don't put stale timestamps in the skb · 37e738b6
      Karol Kolacinski authored
      
      The driver has to check if it does not accidentally put the timestamp in
      the SKB before previous timestamp gets overwritten.
      Timestamp values in the PHY are read only and do not get cleared except
      at hardware reset or when a new timestamp value is captured.
      The cached_tstamp field is used to detect the case where a new timestamp
      has not yet been captured, ensuring that we avoid sending stale
      timestamp data to the stack.
      
      Fixes: ea9b847c ("ice: enable transmit timestamps for E810 devices")
      Signed-off-by: default avatarKarol Kolacinski <karol.kolacinski@intel.com>
      Tested-by: default avatarGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      37e738b6
    • Karol Kolacinski's avatar
      ice: Use div64_u64 instead of div_u64 in adjfine · 0013881c
      Karol Kolacinski authored
      
      Change the division in ice_ptp_adjfine from div_u64 to div64_u64.
      div_u64 is used when the divisor is 32 bit but in this case incval is
      64 bit and it caused incorrect calculations and incval adjustments.
      
      Fixes: 06c16d89 ("ice: register 1588 PTP clock device object for E810 devices")
      Signed-off-by: default avatarKarol Kolacinski <karol.kolacinski@intel.com>
      Tested-by: default avatarGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      0013881c
    • Danielle Ratson's avatar
      mlxsw: spectrum_router: Consolidate MAC profiles when possible · b442f2ea
      Danielle Ratson authored
      
      Currently, when setting a router interface (RIF) MAC address while the
      MAC profile is not shared with other RIFs, the profile is edited so that
      the new MAC address is assigned to it.
      
      This does not take into account a situation in which the new MAC address
      already matches an existing MAC profile. In that situation, two MAC
      profiles will be occupied even though they hold MAC addresses from the
      same profile.
      
      In order to prevent that, add a check to ensure that editing a MAC
      profile takes place only when the new MAC address does not match an
      existing profile.
      
      Fixes: 605d25cd ("mlxsw: spectrum_router: Add RIF MAC profiles support")
      Reported-by: default avatarMaksym Yaremchuk <maksymy@nvidia.com>
      Tested-by: default avatarMaksym Yaremchuk <maksymy@nvidia.com>
      Signed-off-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b442f2ea
    • Ong Boon Leong's avatar
      net: stmmac: fix tc flower deletion for VLAN priority Rx steering · aeb7c75c
      Ong Boon Leong authored
      
      To replicate the issue:-
      
      1) Add 1 flower filter for VLAN Priority based frame steering:-
      $ IFDEVNAME=eth0
      $ tc qdisc add dev $IFDEVNAME ingress
      $ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \
         map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \
         queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0
      $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \
         flower vlan_prio 0 hw_tc 0
      
      2) Get the 'pref' id
      $ tc filter show dev $IFDEVNAME ingress
      
      3) Delete a specific tc flower record (say pref 49151)
      $ tc filter del dev $IFDEVNAME parent ffff: pref 49151
      
      From dmesg, we will observe kernel NULL pointer ooops
      
      [  197.170464] BUG: kernel NULL pointer dereference, address: 0000000000000000
      [  197.171367] #PF: supervisor read access in kernel mode
      [  197.171367] #PF: error_code(0x0000) - not-present page
      [  197.171367] PGD 0 P4D 0
      [  197.171367] Oops: 0000 [#1] PREEMPT SMP NOPTI
      
      <snip>
      
      [  197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac]
      
      <snip>
      
      [  197.171367] Call Trace:
      [  197.171367]  <TASK>
      [  197.171367]  ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac]
      [  197.171367]  stmmac_setup_tc_block_cb+0x70/0x110 [stmmac]
      [  197.171367]  tc_setup_cb_destroy+0xb3/0x180
      [  197.171367]  fl_hw_destroy_filter+0x94/0xc0 [cls_flower]
      
      The above issue is due to previous incorrect implementation of
      tc_del_vlan_flow(), shown below, that uses flow_cls_offload_flow_rule()
      to get struct flow_rule *rule which is no longer valid for tc filter
      delete operation.
      
        struct flow_rule *rule = flow_cls_offload_flow_rule(cls);
        struct flow_dissector *dissector = rule->match.dissector;
      
      So, to ensure tc_del_vlan_flow() deletes the right VLAN cls record for
      earlier configured RX queue (configured by hw_tc) in tc_add_vlan_flow(),
      this patch introduces stmmac_rfs_entry as driver-side flow_cls_offload
      record for 'RX frame steering' tc flower, currently used for VLAN
      priority. The implementation has taken consideration for future extension
      to include other type RX frame steering such as EtherType based.
      
      v2:
       - Clean up overly extensive backtrace and rewrite git message to better
         explain the kernel NULL pointer issue.
      
      Fixes: 0e039f5c ("net: stmmac: add RX frame steering based on VLAN priority in tc flower")
      Tested-by: default avatarKurt Kanzenbach <kurt@linutronix.de>
      Signed-off-by: default avatarOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aeb7c75c
  8. Dec 13, 2021
Loading