1. 21 Feb, 2023 2 commits
  2. 20 Feb, 2023 6 commits
    • Doug Berger's avatar
      net: bcmgenet: fix MoCA LED control · a7515af9
      Doug Berger authored
      When the bcmgenet_mii_config() code was refactored it was missed
      that the LED control for the MoCA interface got overwritten by
      the port_ctrl value. Its previous programming is restored here.
      
      Fixes: 4f8d81b7 ("net: bcmgenet: Refactor register access in bcmgenet_mii_config")
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7515af9
    • Shigeru Yoshida's avatar
      l2tp: Avoid possible recursive deadlock in l2tp_tunnel_register() · 9ca5e7ec
      Shigeru Yoshida authored
      When a file descriptor of pppol2tp socket is passed as file descriptor
      of UDP socket, a recursive deadlock occurs in l2tp_tunnel_register().
      This situation is reproduced by the following program:
      
      int main(void)
      {
      	int sock;
      	struct sockaddr_pppol2tp addr;
      
      	sock = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP);
      	if (sock < 0) {
      		perror("socket");
      		return 1;
      	}
      
      	addr.sa_family = AF_PPPOX;
      	addr.sa_protocol = PX_PROTO_OL2TP;
      	addr.pppol2tp.pid = 0;
      	addr.pppol2tp.fd = sock;
      	addr.pppol2tp.addr.sin_family = PF_INET;
      	addr.pppol2tp.addr.sin_port = htons(0);
      	addr.pppol2tp.addr.sin_addr.s_addr = inet_addr("192.168.0.1");
      	addr.pppol2tp.s_tunnel = 1;
      	addr.pppol2tp.s_session = 0;
      	addr.pppol2tp.d_tunnel = 0;
      	addr.pppol2tp.d_session = 0;
      
      	if (connect(sock, (const struct sockaddr *)&addr, sizeof(addr)) < 0) {
      		perror("connect");
      		return 1;
      	}
      
      	return 0;
      }
      
      This program causes the following lockdep warning:
      
       ============================================
       WARNING: possible recursive locking detected
       6.2.0-rc5-00205-gc9661827 #56 Not tainted
       --------------------------------------------
       repro/8607 is trying to acquire lock:
       ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: l2tp_tunnel_register+0x2b7/0x11c0
      
       but task is already holding lock:
       ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: pppol2tp_connect+0xa82/0x1a30
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(sk_lock-AF_PPPOX);
         lock(sk_lock-AF_PPPOX);
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       1 lock held by repro/8607:
        #0: ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: pppol2tp_connect+0xa82/0x1a30
      
       stack backtrace:
       CPU: 0 PID: 8607 Comm: repro Not tainted 6.2.0-rc5-00205-gc9661827 #56
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
       Call Trace:
        <TASK>
        dump_stack_lvl+0x100/0x178
        __lock_acquire.cold+0x119/0x3b9
        ? lockdep_hardirqs_on_prepare+0x410/0x410
        lock_acquire+0x1e0/0x610
        ? l2tp_tunnel_register+0x2b7/0x11c0
        ? lock_downgrade+0x710/0x710
        ? __fget_files+0x283/0x3e0
        lock_sock_nested+0x3a/0xf0
        ? l2tp_tunnel_register+0x2b7/0x11c0
        l2tp_tunnel_register+0x2b7/0x11c0
        ? sprintf+0xc4/0x100
        ? l2tp_tunnel_del_work+0x6b0/0x6b0
        ? debug_object_deactivate+0x320/0x320
        ? lockdep_init_map_type+0x16d/0x7a0
        ? lockdep_init_map_type+0x16d/0x7a0
        ? l2tp_tunnel_create+0x2bf/0x4b0
        ? l2tp_tunnel_create+0x3c6/0x4b0
        pppol2tp_connect+0x14e1/0x1a30
        ? pppol2tp_put_sk+0xd0/0xd0
        ? aa_sk_perm+0x2b7/0xa80
        ? aa_af_perm+0x260/0x260
        ? bpf_lsm_socket_connect+0x9/0x10
        ? pppol2tp_put_sk+0xd0/0xd0
        __sys_connect_file+0x14f/0x190
        __sys_connect+0x133/0x160
        ? __sys_connect_file+0x190/0x190
        ? lockdep_hardirqs_on+0x7d/0x100
        ? ktime_get_coarse_real_ts64+0x1b7/0x200
        ? ktime_get_coarse_real_ts64+0x147/0x200
        ? __audit_syscall_entry+0x396/0x500
        __x64_sys_connect+0x72/0xb0
        do_syscall_64+0x38/0xb0
        entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      This patch fixes the issue by getting/creating the tunnel before
      locking the pppol2tp socket.
      
      Fixes: 0b2c5972 ("l2tp: close all race conditions in l2tp_tunnel_register()")
      Cc: Cong Wang <cong.wang@bytedance.com>
      Signed-off-by: default avatarShigeru Yoshida <syoshida@redhat.com>
      Reviewed-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ca5e7ec
    • Jakub Sitnicki's avatar
      selftests/net: Interpret UDP_GRO cmsg data as an int value · 43686409
      Jakub Sitnicki authored
      Data passed to user-space with a (SOL_UDP, UDP_GRO) cmsg carries an
      int (see udp_cmsg_recv), not a u16 value, as strace confirms:
      
        recvmsg(8, {msg_name=...,
                    msg_iov=[{iov_base="\0\0..."..., iov_len=96000}],
                    msg_iovlen=1,
                    msg_control=[{cmsg_len=20,         <-- sizeof(cmsghdr) + 4
                                  cmsg_level=SOL_UDP,
                                  cmsg_type=0x68}],    <-- UDP_GRO
                                  msg_controllen=24,
                                  msg_flags=0}, 0) = 11200
      
      Interpreting the data as an u16 value won't work on big-endian platforms.
      Since it is too late to back out of this API decision [1], fix the test.
      
      [1]: https://lore.kernel.org/netdev/20230131174601.203127-1-jakub@cloudflare.com/
      
      Fixes: 3327a9c4 ("selftests: add functionals test for UDP GRO")
      Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43686409
    • Manish Chopra's avatar
      qede: fix interrupt coalescing configuration · 908d4bb7
      Manish Chopra authored
      On default driver load device gets configured with unexpected
      higher interrupt coalescing values instead of default expected
      values as memory allocated from krealloc() is not supposed to
      be zeroed out and may contain garbage values.
      
      Fix this by allocating the memory of required size first with
      kcalloc() and then use krealloc() to resize and preserve the
      contents across down/up of the interface.
      Signed-off-by: default avatarManish Chopra <manishc@marvell.com>
      Fixes: b0ec5489 ("qede: preserve per queue stats across up/down of interface")
      Cc: stable@vger.kernel.org
      Cc: Bhaskar Upadhaya <bupadhaya@marvell.com>
      Cc: David S. Miller <davem@davemloft.net>
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=2160054Signed-off-by: default avatarAlok Prasad <palok@marvell.com>
      Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      908d4bb7
    • D. Wythe's avatar
      net/smc: fix application data exception · 475f9ff6
      D. Wythe authored
      There is a certain probability that following
      exceptions will occur in the wrk benchmark test:
      
      Running 10s test @ http://11.213.45.6:80
        8 threads and 64 connections
        Thread Stats   Avg      Stdev     Max   +/- Stdev
          Latency     3.72ms   13.94ms 245.33ms   94.17%
          Req/Sec     1.96k   713.67     5.41k    75.16%
        155262 requests in 10.10s, 23.10MB read
      Non-2xx or 3xx responses: 3
      
      We will find that the error is HTTP 400 error, which is a serious
      exception in our test, which means the application data was
      corrupted.
      
      Consider the following scenarios:
      
      CPU0                            CPU1
      
      buf_desc->used = 0;
                                      cmpxchg(buf_desc->used, 0, 1)
                                      deal_with(buf_desc)
      
      memset(buf_desc->cpu_addr,0);
      
      This will cause the data received by a victim connection to be cleared,
      thus triggering an HTTP 400 error in the server.
      
      This patch exchange the order between clear used and memset, add
      barrier to ensure memory consistency.
      
      Fixes: 1c552696 ("net/smc: Clear memory when release and reuse buffer")
      Signed-off-by: default avatarD. Wythe <alibuda@linux.alibaba.com>
      Reviewed-by: default avatarWenjia Zhang <wenjia@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      475f9ff6
    • D. Wythe's avatar
      net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link() · e40b801b
      D. Wythe authored
      There is a certain chance to trigger the following panic:
      
      PID: 5900   TASK: ffff88c1c8af4100  CPU: 1   COMMAND: "kworker/1:48"
       #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7
       #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a
       #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60
       #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7
       #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715
       #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654
       #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62
          [exception RIP: ib_alloc_mr+19]
          RIP: ffffffffc0c9cce3  RSP: ffff9456c1cc7c38  RFLAGS: 00010202
          RAX: 0000000000000000  RBX: 0000000000000002  RCX: 0000000000000004
          RDX: 0000000000000010  RSI: 0000000000000000  RDI: 0000000000000000
          RBP: ffff88c1ea281d00   R8: 000000020a34ffff   R9: ffff88c1350bbb20
          R10: 0000000000000000  R11: 0000000000000001  R12: 0000000000000000
          R13: 0000000000000010  R14: ffff88c1ab040a50  R15: ffff88c1ea281d00
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc]
       #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc]
       #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]
      
      The reason here is that when the server tries to create a second link,
      smc_llc_srv_add_link() has no protection and may add a new link to
      link group. This breaks the security environment protected by
      llc_conf_mutex.
      
      Fixes: 2d2209f2 ("net/smc: first part of add link processing as SMC server")
      Signed-off-by: default avatarD. Wythe <alibuda@linux.alibaba.com>
      Reviewed-by: default avatarLarysa Zaremba <larysa.zaremba@intel.com>
      Reviewed-by: default avatarWenjia Zhang <wenjia@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e40b801b
  3. 17 Feb, 2023 1 commit
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2023-02-17' of git://anongit.freedesktop.org/drm/drm · ec35307e
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Just a final collection of misc fixes, the biggest disables the
        recently added dynamic debugging support, it has a regression that
        needs some bigger fixes.
      
        Otherwise a bunch of fixes across the board, vc4, amdgpu and vmwgfx
        mostly, with some smaller i915 and ast fixes.
      
        drm:
         - dynamic debug disable for now
      
        fbdev:
         - deferred i/o device close fix
      
        amdgpu:
         - Fix GC11.x suspend warning
         - Fix display warning
      
        vc4:
         - YUV planes fix
         - hdmi display fix
         - crtc reduced blanking fix
      
        ast:
         - fix start address computation
      
        vmwgfx:
         - fix bo/handle races
      
        i915:
         - gen11 WA fix"
      
      * tag 'drm-fixes-2023-02-17' of git://anongit.freedesktop.org/drm/drm:
        drm/amd/display: Fail atomic_check early on normalize_zpos error
        drm/amd/amdgpu: fix warning during suspend
        drm/vmwgfx: Do not drop the reference to the handle too soon
        drm/vmwgfx: Stop accessing buffer objects which failed init
        drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list
        drm: Disable dynamic debug as broken
        drm/ast: Fix start address computation
        fbdev: Fix invalid page access after closing deferred I/O devices
        drm/vc4: crtc: Increase setup cost in core clock calculation to handle extreme reduced blanking
        drm/vc4: hdmi: Always enable GCP with AVMUTE cleared
        drm/vc4: Fix YUV plane handling when planes are in different buffers
      ec35307e
  4. 16 Feb, 2023 15 commits
  5. 15 Feb, 2023 16 commits
    • Linus Torvalds's avatar
      Merge tag 'apparmor-v6.2-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor · 033c40a8
      Linus Torvalds authored
      Pull apparmor fix from John Johansen:
       "Regression fix for getattr mediation of old policy"
      
      * tag 'apparmor-v6.2-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor:
        apparmor: Fix regression in compat permissions for getattr
      033c40a8
    • Jens Axboe's avatar
      Merge tag 'nvme-6.2-2023-02-15' of git://git.infradead.org/nvme into block-6.2 · 9a28b92c
      Jens Axboe authored
      Pull NVMe fixes from Christoph:
      
      "nvme fixes for Linux 6.2
      
       - always return an ERR_PTR from nvme_pci_alloc_dev (Irvin Cote)
       - add bogus ID quirk for ADATA SX6000PNP (Daniel Wagner)
       - set the DMA mask earlier (Christoph Hellwig)"
      
      * tag 'nvme-6.2-2023-02-15' of git://git.infradead.org/nvme:
        nvme-pci: always return an ERR_PTR from nvme_pci_alloc_dev
        nvme-pci: set the DMA mask earlier
        nvme-pci: add bogus ID quirk for ADATA SX6000PNP
      9a28b92c
    • Linus Torvalds's avatar
      Merge tag 'nfsd-6.2-6' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux · 3402351a
      Linus Torvalds authored
      Pull nfsd fix from Chuck Lever:
      
       - Fix a teardown bug in the new nfs4_file hashtable
      
      * tag 'nfsd-6.2-6' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux:
        nfsd: don't destroy global nfs4_file table in per-net shutdown
      3402351a
    • Linus Torvalds's avatar
      Merge tag 'trace-v6.2-rc7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace · ca5ca227
      Linus Torvalds authored
      Pull tracing fixlet from Steven Rostedt:
       "Make trace_define_field_ext() static.
      
        Just after the fix to TASK_COMM_LEN not converted to its value in
        trace_events was pulled, the kernel test robot reported that the
        helper function trace_define_field_ext() added to that change was only
        used in the file it was defined in but was not declared static.
      
        Make it a local function"
      
      * tag 'trace-v6.2-rc7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
        tracing: Make trace_define_field_ext() static
      ca5ca227
    • John Johansen's avatar
      apparmor: Fix regression in compat permissions for getattr · cbb13e12
      John Johansen authored
      This fixes a regression in mediation of getattr when old policy built
      under an older ABI is loaded and mapped to internal permissions.
      
      The regression does not occur for all getattr permission requests,
      only appearing if state zero is the final state in the permission
      lookup.  This is because despite the first state (index 0) being
      guaranteed to not have permissions in both newer and older permission
      formats, it may have to carry permissions that were not mediated as
      part of an older policy. These backward compat permissions are
      mapped here to avoid special casing the mediation code paths.
      
      Since the mapping code already takes into account backwards compat
      permission from older formats it can be applied to state 0 to fix
      the regression.
      
      Fixes: 408d53e9 ("apparmor: compute file permissions on profile load")
      Reported-by: default avatarPhilip Meulengracht <the_meulengracht@hotmail.com>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      cbb13e12
    • Linus Walleij's avatar
      gpio: mlxbf2: select GPIOLIB_IRQCHIP · 2f43f602
      Linus Walleij authored
      This driver uncondictionally uses the GPIOLIB_IRQCHIP so
      select it.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
      2f43f602
    • Werner Sembach's avatar
      gpiolib: acpi: Add a ignore wakeup quirk for Clevo NH5xAx · a69982c3
      Werner Sembach authored
      The commit 1796f808 ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
      changed the policy such that I2C touchpads may be able to wake up the
      system by default if the system is configured as such.
      
      However for some devices there is a bug, that is causing the touchpad to
      instantly wake up the device again once it gets deactivated. The root cause
      is still under investigation (see Link tag).
      
      To workaround this problem for the time being, introduce a quirk for this
      model that will prevent the wakeup capability for being set for GPIO 16.
      
      Fixes: 1796f808 ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
      Link: https://lore.kernel.org/linux-acpi/20230210164636.628462-1-wse@tuxedocomputers.com/Signed-off-by: default avatarWerner Sembach <wse@tuxedocomputers.com>
      Cc: <stable@vger.kernel.org> # v6.1+
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      a69982c3
    • Alexander Stein's avatar
      gpio: vf610: make irq_chip immutable · e6ef4f8e
      Alexander Stein authored
      Since recently, the kernel is nagging about mutable irq_chips:
      
          "not an immutable chip, please consider fixing it!"
      
      Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new
      helper functions and call the appropriate gpiolib functions.
      Signed-off-by: default avatarAlexander Stein <alexander.stein@ew.tq-group.com>
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
      e6ef4f8e
    • Raag Jadav's avatar
      gpiolib: acpi: remove redundant declaration · b61494d0
      Raag Jadav authored
      Remove acpi_device declaration, as it is no longer needed.
      Signed-off-by: default avatarRaag Jadav <raag.jadav@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      b61494d0
    • Jakub Kicinski's avatar
      net: mpls: fix stale pointer if allocation fails during device rename · fda6c89f
      Jakub Kicinski authored
      lianhui reports that when MPLS fails to register the sysctl table
      under new location (during device rename) the old pointers won't
      get overwritten and may be freed again (double free).
      
      Handle this gracefully. The best option would be unregistering
      the MPLS from the device completely on failure, but unfortunately
      mpls_ifdown() can fail. So failing fully is also unreliable.
      
      Another option is to register the new table first then only
      remove old one if the new one succeeds. That requires more
      code, changes order of notifications and two tables may be
      visible at the same time.
      
      sysctl point is not used in the rest of the code - set to NULL
      on failures and skip unregister if already NULL.
      Reported-by: default avatarlianhui tang <bluetlh@gmail.com>
      Fixes: 0fae3bf0 ("mpls: handle device renames for per-device sysctls")
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fda6c89f
    • Pedro Tammela's avatar
      net/sched: tcindex: search key must be 16 bits · 42018a32
      Pedro Tammela authored
      Syzkaller found an issue where a handle greater than 16 bits would trigger
      a null-ptr-deref in the imperfect hash area update.
      
      general protection fault, probably for non-canonical address
      0xdffffc0000000015: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af]
      CPU: 0 PID: 5070 Comm: syz-executor456 Not tainted
      6.2.0-rc7-syzkaller-00112-gc68f345b #0
      Hardware name: Google Google Compute Engine/Google Compute Engine,
      BIOS Google 01/21/2023
      RIP: 0010:tcindex_set_parms+0x1a6a/0x2990 net/sched/cls_tcindex.c:509
      Code: 01 e9 e9 fe ff ff 4c 8b bd 28 fe ff ff e8 0e 57 7d f9 48 8d bb
      a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c
      02 00 0f 85 94 0c 00 00 48 8b 85 f8 fd ff ff 48 8b 9b a8 00
      RSP: 0018:ffffc90003d3ef88 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000015 RSI: ffffffff8803a102 RDI: 00000000000000a8
      RBP: ffffc90003d3f1d8 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000000 R12: ffff88801e2b10a8
      R13: dffffc0000000000 R14: 0000000000030000 R15: ffff888017b3be00
      FS: 00005555569af300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000056041c6d2000 CR3: 000000002bfca000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
      <TASK>
      tcindex_change+0x1ea/0x320 net/sched/cls_tcindex.c:572
      tc_new_tfilter+0x96e/0x2220 net/sched/cls_api.c:2155
      rtnetlink_rcv_msg+0x959/0xca0 net/core/rtnetlink.c:6132
      netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
      netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
      netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
      netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1942
      sock_sendmsg_nosec net/socket.c:714 [inline]
      sock_sendmsg+0xd3/0x120 net/socket.c:734
      ____sys_sendmsg+0x334/0x8c0 net/socket.c:2476
      ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530
      __sys_sendmmsg+0x18f/0x460 net/socket.c:2616
      __do_sys_sendmmsg net/socket.c:2645 [inline]
      __se_sys_sendmmsg net/socket.c:2642 [inline]
      __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2642
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
      
      Fixes: ee059170 ("net/sched: tcindex: update imperfect hash filters respecting rcu")
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarPedro Tammela <pctammela@mojatatu.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42018a32
    • Tung Nguyen's avatar
      tipc: fix kernel warning when sending SYN message · 11a4d6f6
      Tung Nguyen authored
      When sending a SYN message, this kernel stack trace is observed:
      
      ...
      [   13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550
      ...
      [   13.398494] Call Trace:
      [   13.398630]  <TASK>
      [   13.398630]  ? __alloc_skb+0xed/0x1a0
      [   13.398630]  tipc_msg_build+0x12c/0x670 [tipc]
      [   13.398630]  ? shmem_add_to_page_cache.isra.71+0x151/0x290
      [   13.398630]  __tipc_sendmsg+0x2d1/0x710 [tipc]
      [   13.398630]  ? tipc_connect+0x1d9/0x230 [tipc]
      [   13.398630]  ? __local_bh_enable_ip+0x37/0x80
      [   13.398630]  tipc_connect+0x1d9/0x230 [tipc]
      [   13.398630]  ? __sys_connect+0x9f/0xd0
      [   13.398630]  __sys_connect+0x9f/0xd0
      [   13.398630]  ? preempt_count_add+0x4d/0xa0
      [   13.398630]  ? fpregs_assert_state_consistent+0x22/0x50
      [   13.398630]  __x64_sys_connect+0x16/0x20
      [   13.398630]  do_syscall_64+0x42/0x90
      [   13.398630]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      It is because commit a41dad90 ("iov_iter: saner checks for attempt
      to copy to/from iterator") has introduced sanity check for copying
      from/to iov iterator. Lacking of copy direction from the iterator
      viewpoint would lead to kernel stack trace like above.
      
      This commit fixes this issue by initializing the iov iterator with
      the correct copy direction when sending SYN or ACK without data.
      
      Fixes: f25dcc76 ("tipc: tipc ->sendmsg() conversion")
      Reported-by: syzbot+d43608d061e8847ec9f3@syzkaller.appspotmail.com
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Signed-off-by: default avatarTung Nguyen <tung.q.nguyen@dektech.com.au>
      Link: https://lore.kernel.org/r/20230214012606.5804-1-tung.q.nguyen@dektech.com.auSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      11a4d6f6
    • Miroslav Lichvar's avatar
      igb: Fix PPS input and output using 3rd and 4th SDP · 207ce626
      Miroslav Lichvar authored
      Fix handling of the tsync interrupt to compare the pin number with
      IGB_N_SDP instead of IGB_N_EXTTS/IGB_N_PEROUT and fix the indexing to
      the perout array.
      
      Fixes: cf99c1dd ("igb: move PEROUT and EXTTS isr logic to separate functions")
      Reported-by: default avatarMatt Corallo <ntp-lists@mattcorallo.com>
      Signed-off-by: default avatarMiroslav Lichvar <mlichvar@redhat.com>
      Reviewed-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Link: https://lore.kernel.org/r/20230213185822.3960072-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      207ce626
    • Jakub Kicinski's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue · d3a37346
      Jakub Kicinski authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2023-02-13 (ice)
      
      This series contains updates to ice driver only.
      
      Michal fixes check of scheduling node weight and priority to be done
      against desired value, not current value.
      
      Jesse adds setting of all multicast when adding promiscuous mode to
      resolve traffic being lost due to filter settings.
      
      * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
        ice: fix lost multicast packets in promisc mode
        ice: Fix check for weight and priority of a scheduling node
      ====================
      
      Link: https://lore.kernel.org/r/20230213185259.3959224-1-anthony.l.nguyen@intel.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d3a37346
    • Eric Dumazet's avatar
      net: use a bounce buffer for copying skb->mark · 2558b803
      Eric Dumazet authored
      syzbot found arm64 builds would crash in sock_recv_mark()
      when CONFIG_HARDENED_USERCOPY=y
      
      x86 and powerpc are not detecting the issue because
      they define user_access_begin.
      This will be handled in a different patch,
      because a check_object_size() is missing.
      
      Only data from skb->cb[] can be copied directly to/from user space,
      as explained in commit 79a8a642 ("net: Whitelist
      the skbuff_head_cache "cb" field")
      
      syzbot report was:
      usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_head_cache' (offset 168, size 4)!
      ------------[ cut here ]------------
      kernel BUG at mm/usercopy.c:102 !
      Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0 PID: 4410 Comm: syz-executor533 Not tainted 6.2.0-rc7-syzkaller-17907-g2d3827b3f393 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023
      pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      pc : usercopy_abort+0x90/0x94 mm/usercopy.c:90
      lr : usercopy_abort+0x90/0x94 mm/usercopy.c:90
      sp : ffff80000fb9b9a0
      x29: ffff80000fb9b9b0 x28: ffff0000c6073400 x27: 0000000020001a00
      x26: 0000000000000014 x25: ffff80000cf52000 x24: fffffc0000000000
      x23: 05ffc00000000200 x22: fffffc000324bf80 x21: ffff0000c92fe1a8
      x20: 0000000000000001 x19: 0000000000000004 x18: 0000000000000000
      x17: 656a626f2042554c x16: ffff0000c6073dd0 x15: ffff80000dbd2118
      x14: ffff0000c6073400 x13: 00000000ffffffff x12: ffff0000c6073400
      x11: ff808000081bbb4c x10: 0000000000000000 x9 : 7b0572d7cc0ccf00
      x8 : 7b0572d7cc0ccf00 x7 : ffff80000bf650d4 x6 : 0000000000000000
      x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000
      x2 : ffff0001fefbff08 x1 : 0000000100000000 x0 : 000000000000006c
      Call trace:
      usercopy_abort+0x90/0x94 mm/usercopy.c:90
      __check_heap_object+0xa8/0x100 mm/slub.c:4761
      check_heap_object mm/usercopy.c:196 [inline]
      __check_object_size+0x208/0x6b8 mm/usercopy.c:251
      check_object_size include/linux/thread_info.h:199 [inline]
      __copy_to_user include/linux/uaccess.h:115 [inline]
      put_cmsg+0x408/0x464 net/core/scm.c:238
      sock_recv_mark net/socket.c:975 [inline]
      __sock_recv_cmsgs+0x1fc/0x248 net/socket.c:984
      sock_recv_cmsgs include/net/sock.h:2728 [inline]
      packet_recvmsg+0x2d8/0x678 net/packet/af_packet.c:3482
      ____sys_recvmsg+0x110/0x3a0
      ___sys_recvmsg net/socket.c:2737 [inline]
      __sys_recvmsg+0x194/0x210 net/socket.c:2767
      __do_sys_recvmsg net/socket.c:2777 [inline]
      __se_sys_recvmsg net/socket.c:2774 [inline]
      __arm64_sys_recvmsg+0x2c/0x3c net/socket.c:2774
      __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
      invoke_syscall+0x64/0x178 arch/arm64/kernel/syscall.c:52
      el0_svc_common+0xbc/0x180 arch/arm64/kernel/syscall.c:142
      do_el0_svc+0x48/0x110 arch/arm64/kernel/syscall.c:193
      el0_svc+0x58/0x14c arch/arm64/kernel/entry-common.c:637
      el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
      el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
      Code: 91388800 aa0903e1 f90003e8 94e6d752 (d4210000)
      
      Fixes: 6fd1d51c ("net: SO_RCVMARK socket option for SO_MARK with recvmsg()")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Erin MacNeil <lnx.erin@gmail.com>
      Reviewed-by: default avatarAlexander Lobakin <alexandr.lobakin@intel.com>
      Link: https://lore.kernel.org/r/20230213160059.3829741-1-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2558b803
    • Zack Rusin's avatar
      drm/vmwgfx: Do not drop the reference to the handle too soon · a950b989
      Zack Rusin authored
      v3: Fix vmw_user_bo_lookup which was also dropping the gem reference
      before the kernel was done with buffer depending on userspace doing
      the right thing. Same bug, different spot.
      
      It is possible for userspace to predict the next buffer handle and
      to destroy the buffer while it's still used by the kernel. Delay
      dropping the internal reference on the buffers until kernel is done
      with them.
      
      Instead of immediately dropping the gem reference in vmw_user_bo_lookup
      and vmw_gem_object_create_with_handle let the callers decide when they're
      ready give the control back to userspace.
      
      Also fixes the second usage of vmw_gem_object_create_with_handle in
      vmwgfx_surface.c which wasn't grabbing an explicit reference
      to the gem object which could have been destroyed by the userspace
      on the owning surface at any point.
      Signed-off-by: default avatarZack Rusin <zackr@vmware.com>
      Fixes: 8afa13a0 ("drm/vmwgfx: Implement DRIVER_GEM")
      Reviewed-by: default avatarMartin Krastev <krastevm@vmware.com>
      Reviewed-by: default avatarMaaz Mombasawala <mombasawalam@vmware.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20230211050514.2431155-1-zack@kde.org
      (cherry picked from commit 9ef8d83e)
      Cc: <stable@vger.kernel.org> # v5.17+
      a950b989