Skip to content
  1. Feb 18, 2023
  2. Feb 17, 2023
  3. Feb 16, 2023
  4. Feb 15, 2023
    • 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
    • Munehisa Kamata's avatar
      sched/psi: Fix use-after-free in ep_remove_wait_queue() · c2dbe32d
      Munehisa Kamata authored
      If a non-root cgroup gets removed when there is a thread that registered
      trigger and is polling on a pressure file within the cgroup, the polling
      waitqueue gets freed in the following path:
      
       do_rmdir
         cgroup_rmdir
           kernfs_drain_open_files
             cgroup_file_release
               cgroup_pressure_release
                 psi_trigger_destroy
      
      However, the polling thread still has a reference to the pressure file and
      will access the freed waitqueue when the file is closed or upon exit:
      
       fput
         ep_eventpoll_release
           ep_free
             ep_remove_wait_queue
               remove_wait_queue
      
      This results in use-after-free as pasted below.
      
      The fundamental problem here is that cgroup_file_release() (and
      consequently waitqueue's lifetime) is not tied to the file's real lifetime.
      Using wake_up_pollfree() here might be less than ideal, but it is in line
      with the comment at commit 42288cb4 ("wait: add wake_up_pollfree()")
      since the waitqueue's lifetime is not tied to file's one and can be
      considered as another special case. While this would be fixable by somehow
      making cgroup_file_release() be tied to the fput(), it would require
      sizable refactoring at cgroups or higher layer which might be more
      justifiable if we identify more cases like this.
      
        BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0
        Write of size 4 at addr ffff88810e625328 by task a.out/4404
      
      	CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38
      	Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
      	Call Trace:
      	<TASK>
      	dump_stack_lvl+0x73/0xa0
      	print_report+0x16c/0x4e0
      	kasan_report+0xc3/0xf0
      	kasan_check_range+0x2d2/0x310
      	_raw_spin_lock_irqsave+0x60/0xc0
      	remove_wait_queue+0x1a/0xa0
      	ep_free+0x12c/0x170
      	ep_eventpoll_release+0x26/0x30
      	__fput+0x202/0x400
      	task_work_run+0x11d/0x170
      	do_exit+0x495/0x1130
      	do_group_exit+0x100/0x100
      	get_signal+0xd67/0xde0
      	arch_do_signal_or_restart+0x2a/0x2b0
      	exit_to_user_mode_prepare+0x94/0x100
      	syscall_exit_to_user_mode+0x20/0x40
      	do_syscall_64+0x52/0x90
      	entry_SYSCALL_64_after_hwframe+0x63/0xcd
      	</TASK>
      
       Allocated by task 4404:
      
      	kasan_set_track+0x3d/0x60
      	__kasan_kmalloc+0x85/0x90
      	psi_trigger_create+0x113/0x3e0
      	pressure_write+0x146/0x2e0
      	cgroup_file_write+0x11c/0x250
      	kernfs_fop_write_iter+0x186/0x220
      	vfs_write+0x3d8/0x5c0
      	ksys_write+0x90/0x110
      	do_syscall_64+0x43/0x90
      	entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
       Freed by task 4407:
      
      	kasan_set_track+0x3d/0x60
      	kasan_save_free_info+0x27/0x40
      	____kasan_slab_free+0x11d/0x170
      	slab_free_freelist_hook+0x87/0x150
      	__kmem_cache_free+0xcb/0x180
      	psi_trigger_destroy+0x2e8/0x310
      	cgroup_file_release+0x4f/0xb0
      	kernfs_drain_open_files+0x165/0x1f0
      	kernfs_drain+0x162/0x1a0
      	__kernfs_remove+0x1fb/0x310
      	kernfs_remove_by_name_ns+0x95/0xe0
      	cgroup_addrm_files+0x67f/0x700
      	cgroup_destroy_locked+0x283/0x3c0
      	cgroup_rmdir+0x29/0x100
      	kernfs_iop_rmdir+0xd1/0x140
      	vfs_rmdir+0xfe/0x240
      	do_rmdir+0x13d/0x280
      	__x64_sys_rmdir+0x2c/0x30
      	do_syscall_64+0x43/0x90
      	entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Fixes: 0e94682b
      
       ("psi: introduce psi monitor")
      Signed-off-by: default avatarMunehisa Kamata <kamatam@amazon.com>
      Signed-off-by: default avatarMengchi Cheng <mengcc@amazon.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarSuren Baghdasaryan <surenb@google.com>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/lkml/20230106224859.4123476-1-kamatam@amazon.com/
      Link: https://lore.kernel.org/r/20230214212705.4058045-1-kamatam@amazon.com
      c2dbe32d
    • 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-gc68f345b7c42 #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: default avatar <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.au
      
      
      Signed-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.com
      
      
      Signed-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.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d3a37346