1. 29 Jan, 2024 3 commits
    • Eric Dumazet's avatar
      tcp: add sanity checks to rx zerocopy · 577e4432
      Eric Dumazet authored
      TCP rx zerocopy intent is to map pages initially allocated
      from NIC drivers, not pages owned by a fs.
      
      This patch adds to can_map_frag() these additional checks:
      
      - Page must not be a compound one.
      - page->mapping must be NULL.
      
      This fixes the panic reported by ZhangPeng.
      
      syzbot was able to loopback packets built with sendfile(),
      mapping pages owned by an ext4 file to TCP rx zerocopy.
      
      r3 = socket$inet_tcp(0x2, 0x1, 0x0)
      mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
      r4 = socket$inet_tcp(0x2, 0x1, 0x0)
      bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
      connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
      r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
          0x181e42, 0x0)
      fallocate(r5, 0x0, 0x0, 0x85b8)
      sendfile(r4, r5, 0x0, 0x8ba0)
      getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
          &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,
          0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)
      r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
          0x181e42, 0x0)
      
      Fixes: 93ab6cc6 ("tcp: implement mmap() for zero copy receive")
      Link: https://lore.kernel.org/netdev/5106a58e-04da-372a-b836-9d3d0bd2507b@huawei.com/T/Reported-and-bisected-by: default avatarZhangPeng <zhangpeng362@huawei.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Arjun Roy <arjunroy@google.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: linux-mm@vger.kernel.org
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      577e4432
    • Fedor Pchelkin's avatar
      nfc: nci: free rx_data_reassembly skb on NCI device cleanup · bfb007ae
      Fedor Pchelkin authored
      rx_data_reassembly skb is stored during NCI data exchange for processing
      fragmented packets. It is dropped only when the last fragment is processed
      or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
      However, the NCI device may be deallocated before that which leads to skb
      leak.
      
      As by design the rx_data_reassembly skb is bound to the NCI device and
      nothing prevents the device to be freed before the skb is processed in
      some way and cleaned, free it on the NCI device cleanup.
      
      Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
      
      Fixes: 6a2968aa ("NFC: basic NCI protocol implementation")
      Cc: stable@vger.kernel.org
      Reported-by: syzbot+6b7c68d9c21e4ee4251b@syzkaller.appspotmail.com
      Closes: https://lore.kernel.org/lkml/000000000000f43987060043da7b@google.com/Signed-off-by: default avatarFedor Pchelkin <pchelkin@ispras.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bfb007ae
    • Nikita Zhandarovich's avatar
      net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame() · 37e8c97e
      Nikita Zhandarovich authored
      Syzkaller reported [1] hitting a warning after failing to allocate
      resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
      not help much in this case, it might be prudent to switch to
      netdev_warn_once(). At the very least it will suppress syzkaller
      reports such as [1].
      
      Just in case, use netdev_warn_once() in send_prp_supervision_frame()
      for similar reasons.
      
      [1]
      HSR: Could not send supervision frame
      WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
      RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
      ...
      Call Trace:
       <IRQ>
       hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
       call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
       expire_timers kernel/time/timer.c:1751 [inline]
       __run_timers+0x764/0xb20 kernel/time/timer.c:2022
       run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
       __do_softirq+0x21a/0x8de kernel/softirq.c:553
       invoke_softirq kernel/softirq.c:427 [inline]
       __irq_exit_rcu kernel/softirq.c:632 [inline]
       irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
       sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
       </IRQ>
       <TASK>
       asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
      ...
      
      This issue is also found in older kernels (at least up to 5.10).
      
      Cc: stable@vger.kernel.org
      Reported-by: syzbot+3ae0a3f42c84074b7c8e@syzkaller.appspotmail.com
      Fixes: 121c33b0 ("net: hsr: introduce common code for skb initialization")
      Signed-off-by: default avatarNikita Zhandarovich <n.zhandarovich@fintech.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      37e8c97e
  2. 27 Jan, 2024 3 commits
    • Horatiu Vultur's avatar
      net: lan966x: Fix port configuration when using SGMII interface · 62b42481
      Horatiu Vultur authored
      In case the interface between the MAC and the PHY is SGMII, then the bit
      GIGA_MODE on the MAC side needs to be set regardless of the speed at
      which it is running.
      
      Fixes: d28d6d2e ("net: lan966x: add port module support")
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Reviewed-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      62b42481
    • Simon Horman's avatar
      MAINTAINERS: Add connector headers to NETWORKING DRIVERS · 586e40aa
      Simon Horman authored
      Commit 46cf789b ("connector: Move maintainence under networking
      drivers umbrella.") moved the connector maintenance but did not include
      the connector header files.
      
      It seems that it has always been implied that these headers were
      maintained along with the rest of the connector code, both before and
      after the cited commit. Make this explicit.
      Signed-off-by: default avatarSimon Horman <horms@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      586e40aa
    • Nicolas Dichtel's avatar
      ipmr: fix kernel panic when forwarding mcast packets · e622502c
      Nicolas Dichtel authored
      The stacktrace was:
      [   86.305548] BUG: kernel NULL pointer dereference, address: 0000000000000092
      [   86.306815] #PF: supervisor read access in kernel mode
      [   86.307717] #PF: error_code(0x0000) - not-present page
      [   86.308624] PGD 0 P4D 0
      [   86.309091] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [   86.309883] CPU: 2 PID: 3139 Comm: pimd Tainted: G     U             6.8.0-6wind-knet #1
      [   86.311027] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014
      [   86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)
      [ 86.313399] Code: f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe <80> b8 92 00 00 00 00 0f 84 55 ff ff ff 49 83 47 38 01 45 85 e4 0f
      [   86.316565] RSP: 0018:ffffad21c0583ae0 EFLAGS: 00010246
      [   86.317497] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [   86.318596] RDX: ffff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000
      [   86.319627] RBP: ffffad21c0583b30 R08: 0000000000000000 R09: 0000000000000000
      [   86.320650] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
      [   86.321672] R13: ffff9559c093a000 R14: ffff9559cc00b800 R15: ffff9559c09c1d80
      [   86.322873] FS:  00007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000
      [   86.324291] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   86.325314] CR2: 0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0
      [   86.326589] Call Trace:
      [   86.327036]  <TASK>
      [   86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479)
      [   86.328049] ? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434)
      [   86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707)
      [   86.329107] ? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264)
      [   86.329756] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
      [   86.330350] ? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminator 1))
      [   86.331013] ? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch/x86/mm/fault.c:1563)
      [   86.331702] ? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570)
      [   86.332468] ? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)
      [   86.333183] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
      [   86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet/net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273)
      [   86.334583] ? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363)
      [   86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)
      [   86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
      [   86.336854] ? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)
      [   86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944)
      [   86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862)
      [   86.339232] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
      [   86.339809] ? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181)
      [   86.340342] ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:1415)
      [   86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836)
      [   86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminator 13))
      [   86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716)
      [   86.342747] do_sock_setsockopt (/build/work/knet/net/socket.c:2313)
      [   86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/knet/net/socket.c:2336)
      [   86.344020] __x64_sys_setsockopt (/build/work/knet/net/socket.c:2340)
      [   86.344766] do_syscall_64 (/build/work/knet/arch/x86/entry/common.c:52 /build/work/knet/arch/x86/entry/common.c:83)
      [   86.345433] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
      [   86.346161] ? syscall_exit_work (/build/work/knet/./include/linux/audit.h:357 /build/work/knet/kernel/entry/common.c:160)
      [   86.346938] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
      [   86.347657] ? syscall_exit_to_user_mode (/build/work/knet/kernel/entry/common.c:215)
      [   86.348538] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
      [   86.349262] ? do_syscall_64 (/build/work/knet/./arch/x86/include/asm/cpufeature.h:171 /build/work/knet/arch/x86/entry/common.c:98)
      [   86.349971] entry_SYSCALL_64_after_hwframe (/build/work/knet/arch/x86/entry/entry_64.S:129)
      
      The original packet in ipmr_cache_report() may be queued and then forwarded
      with ip_mr_forward(). This last function has the assumption that the skb
      dst is set.
      
      After the below commit, the skb dst is dropped by ipv4_pktinfo_prepare(),
      which causes the oops.
      
      Fixes: bb740365 ("ipmr: support IP_PKTINFO on cache report IGMP msg")
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20240125141847.1931933-1-nicolas.dichtel@6wind.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e622502c
  3. 26 Jan, 2024 15 commits
  4. 25 Jan, 2024 19 commits