Linux 5.4.244

 
3c589_cs: Fix an error handling path in tc589_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat May 20 11:48:55 2023 +0200

    3c589_cs: Fix an error handling path in tc589_probe()
    
    commit 640bf95b2c7c2981fb471acdafbd3e0458f8390d upstream.
    
    Should tc589_config() fail, some resources need to be released as already
    done in the remove function.
    
    Fixes: 15b99ac17295 ("[PATCH] pcmcia: add return value to _config() functions")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/d8593ae867b24c79063646e36f9b18b0790107cb.1684575975.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ACPI: EC: Fix oops when removing custom query handlers [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Fri Mar 24 21:26:27 2023 +0100

    ACPI: EC: Fix oops when removing custom query handlers
    
    [ Upstream commit e5b492c6bb900fcf9722e05f4a10924410e170c1 ]
    
    When removing custom query handlers, the handler might still
    be used inside the EC query workqueue, causing a kernel oops
    if the module holding the callback function was already unloaded.
    
    Fix this by flushing the EC query workqueue when removing
    custom query handlers.
    
    Tested on a Acer Travelmate 4002WLMi
    
    Signed-off-by: Armin Wolf <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ACPICA: ACPICA: check null return of ACPI_ALLOCATE_ZEROED in acpi_db_display_objects [+ + +]
Author: void0red <[email protected]>
Date:   Wed Apr 5 15:57:57 2023 +0200

    ACPICA: ACPICA: check null return of ACPI_ALLOCATE_ZEROED in acpi_db_display_objects
    
    [ Upstream commit ae5a0eccc85fc960834dd66e3befc2728284b86c ]
    
    ACPICA commit 0d5f467d6a0ba852ea3aad68663cbcbd43300fd4
    
    ACPI_ALLOCATE_ZEROED may fails, object_info might be null and will cause
    null pointer dereference later.
    
    Link: https://github.com/acpica/acpica/commit/0d5f467d
    Signed-off-by: Bob Moore <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPICA: Avoid undefined behavior: applying zero offset to null pointer [+ + +]
Author: Tamir Duberstein <[email protected]>
Date:   Wed Apr 5 15:42:43 2023 +0200

    ACPICA: Avoid undefined behavior: applying zero offset to null pointer
    
    [ Upstream commit 05bb0167c80b8f93c6a4e0451b7da9b96db990c2 ]
    
    ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e
    
    Before this change we see the following UBSAN stack trace in Fuchsia:
    
      #0    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
      #1.2  0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f
      #1.1  0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f
      #1    0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f
      #2    0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d
      #3    0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d
      #4    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
      #5    0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369
      #6    0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac
      #7    0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2
      #8    0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052
      #9    0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8
      #10   0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98
      #11   0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac
      #12   0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d
      #13   0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603
    
    Add a simple check that avoids incrementing a pointer by zero, but
    otherwise behaves as before. Note that our findings are against ACPICA
    20221020, but the same code exists on master.
    
    Link: https://github.com/acpica/acpica/commit/770653e3
    Signed-off-by: Bob Moore <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
af_key: Reject optional tunnel/BEET mode templates in outbound policies [+ + +]
Author: Tobias Brunner <[email protected]>
Date:   Tue May 9 11:00:06 2023 +0200

    af_key: Reject optional tunnel/BEET mode templates in outbound policies
    
    [ Upstream commit cf3128a7aca55b2eefb68281d44749c683bdc96f ]
    
    xfrm_state_find() uses `encap_family` of the current template with
    the passed local and remote addresses to find a matching state.
    If an optional tunnel or BEET mode template is skipped in a mixed-family
    scenario, there could be a mismatch causing an out-of-bounds read as
    the addresses were not replaced to match the family of the next template.
    
    While there are theoretical use cases for optional templates in outbound
    policies, the only practical one is to skip IPComp states in inbound
    policies if uncompressed packets are received that are handled by an
    implicitly created IPIP state instead.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Tobias Brunner <[email protected]>
    Acked-by: Herbert Xu <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
af_unix: Fix a data race of sk->sk_receive_queue->qlen. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue May 9 17:34:55 2023 -0700

    af_unix: Fix a data race of sk->sk_receive_queue->qlen.
    
    [ Upstream commit 679ed006d416ea0cecfe24a99d365d1dea69c683 ]
    
    KCSAN found a data race of sk->sk_receive_queue->qlen where recvmsg()
    updates qlen under the queue lock and sendmsg() checks qlen under
    unix_state_sock(), not the queue lock, so the reader side needs
    READ_ONCE().
    
    BUG: KCSAN: data-race in __skb_try_recv_from_queue / unix_wait_for_peer
    
    write (marked) to 0xffff888019fe7c68 of 4 bytes by task 49792 on cpu 0:
     __skb_unlink include/linux/skbuff.h:2347 [inline]
     __skb_try_recv_from_queue+0x3de/0x470 net/core/datagram.c:197
     __skb_try_recv_datagram+0xf7/0x390 net/core/datagram.c:263
     __unix_dgram_recvmsg+0x109/0x8a0 net/unix/af_unix.c:2452
     unix_dgram_recvmsg+0x94/0xa0 net/unix/af_unix.c:2549
     sock_recvmsg_nosec net/socket.c:1019 [inline]
     ____sys_recvmsg+0x3a3/0x3b0 net/socket.c:2720
     ___sys_recvmsg+0xc8/0x150 net/socket.c:2764
     do_recvmmsg+0x182/0x560 net/socket.c:2858
     __sys_recvmmsg net/socket.c:2937 [inline]
     __do_sys_recvmmsg net/socket.c:2960 [inline]
     __se_sys_recvmmsg net/socket.c:2953 [inline]
     __x64_sys_recvmmsg+0x153/0x170 net/socket.c:2953
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    read to 0xffff888019fe7c68 of 4 bytes by task 49793 on cpu 1:
     skb_queue_len include/linux/skbuff.h:2127 [inline]
     unix_recvq_full net/unix/af_unix.c:229 [inline]
     unix_wait_for_peer+0x154/0x1a0 net/unix/af_unix.c:1445
     unix_dgram_sendmsg+0x13bc/0x14b0 net/unix/af_unix.c:2048
     sock_sendmsg_nosec net/socket.c:724 [inline]
     sock_sendmsg+0x148/0x160 net/socket.c:747
     ____sys_sendmsg+0x20e/0x620 net/socket.c:2503
     ___sys_sendmsg+0xc6/0x140 net/socket.c:2557
     __sys_sendmmsg+0x11d/0x370 net/socket.c:2643
     __do_sys_sendmmsg net/socket.c:2672 [inline]
     __se_sys_sendmmsg net/socket.c:2669 [inline]
     __x64_sys_sendmmsg+0x58/0x70 net/socket.c:2669
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    value changed: 0x0000000b -> 0x00000001
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 49793 Comm: syz-executor.0 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

af_unix: Fix data races around sk->sk_shutdown. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue May 9 17:34:56 2023 -0700

    af_unix: Fix data races around sk->sk_shutdown.
    
    [ Upstream commit e1d09c2c2f5793474556b60f83900e088d0d366d ]
    
    KCSAN found a data race around sk->sk_shutdown where unix_release_sock()
    and unix_shutdown() update it under unix_state_lock(), OTOH unix_poll()
    and unix_dgram_poll() read it locklessly.
    
    We need to annotate the writes and reads with WRITE_ONCE() and READ_ONCE().
    
    BUG: KCSAN: data-race in unix_poll / unix_release_sock
    
    write to 0xffff88800d0f8aec of 1 bytes by task 264 on cpu 0:
     unix_release_sock+0x75c/0x910 net/unix/af_unix.c:631
     unix_release+0x59/0x80 net/unix/af_unix.c:1042
     __sock_release+0x7d/0x170 net/socket.c:653
     sock_close+0x19/0x30 net/socket.c:1397
     __fput+0x179/0x5e0 fs/file_table.c:321
     ____fput+0x15/0x20 fs/file_table.c:349
     task_work_run+0x116/0x1a0 kernel/task_work.c:179
     resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
     exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
     exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204
     __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
     syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297
     do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    read to 0xffff88800d0f8aec of 1 bytes by task 222 on cpu 1:
     unix_poll+0xa3/0x2a0 net/unix/af_unix.c:3170
     sock_poll+0xcf/0x2b0 net/socket.c:1385
     vfs_poll include/linux/poll.h:88 [inline]
     ep_item_poll.isra.0+0x78/0xc0 fs/eventpoll.c:855
     ep_send_events fs/eventpoll.c:1694 [inline]
     ep_poll fs/eventpoll.c:1823 [inline]
     do_epoll_wait+0x6c4/0xea0 fs/eventpoll.c:2258
     __do_sys_epoll_wait fs/eventpoll.c:2270 [inline]
     __se_sys_epoll_wait fs/eventpoll.c:2265 [inline]
     __x64_sys_epoll_wait+0xcc/0x190 fs/eventpoll.c:2265
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    value changed: 0x00 -> 0x03
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 222 Comm: dbus-broker Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    
    Fixes: 3c73419c09a5 ("af_unix: fix 'poll for write'/ connected DGRAM sockets")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: firewire-digi00x: prevent potential use after free [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue May 9 12:07:11 2023 +0300

    ALSA: firewire-digi00x: prevent potential use after free
    
    [ Upstream commit c0e72058d5e21982e61a29de6b098f7c1f0db498 ]
    
    This code was supposed to return an error code if init_stream()
    failed, but it instead freed dg00x->rx_stream and returned success.
    This potentially leads to a use after free.
    
    Fixes: 9a08067ec318 ("ALSA: firewire-digi00x: support AMDTP domain")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/ca0132: add quirk for EVGA X299 DARK [+ + +]
Author: Adam Stylinski <[email protected]>
Date:   Sun May 21 10:52:23 2023 -0400

    ALSA: hda/ca0132: add quirk for EVGA X299 DARK
    
    commit 7843380d07bbeffd3ce6504e73cf61f840ae76ca upstream.
    
    This quirk is necessary for surround and other DSP effects to work
    with the onboard ca0132 based audio chipset for the EVGA X299 dark
    mainboard.
    
    Signed-off-by: Adam Stylinski <[email protected]>
    Cc: <[email protected]>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=67071
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Add a quirk for HP EliteDesk 805 [+ + +]
Author: Ai Chao <[email protected]>
Date:   Sat May 6 10:26:53 2023 +0800

    ALSA: hda/realtek: Add a quirk for HP EliteDesk 805
    
    commit 90670ef774a8b6700c38ce1222e6aa263be54d5f upstream.
    
    Add a quirk for HP EliteDesk 805 to fixup ALC3867 headset MIC no sound.
    
    Signed-off-by: Ai Chao <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Add quirk for 2nd ASUS GU603 [+ + +]
Author: Luke D. Jones <[email protected]>
Date:   Sat May 6 11:58:24 2023 +1200

    ALSA: hda/realtek: Add quirk for 2nd ASUS GU603
    
    commit a4671b7fba59775845ee60cfbdfc4ba64300211b upstream.
    
    Add quirk for GU603 with 0x1c62 variant of codec.
    
    Signed-off-by: Luke D. Jones <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Enable headset onLenovo M70/M90 [+ + +]
Author: Bin Li <[email protected]>
Date:   Wed May 24 19:37:55 2023 +0800

    ALSA: hda/realtek: Enable headset onLenovo M70/M90
    
    commit 4ca110cab46561cd74a2acd9b447435acb4bec5f upstream.
    
    Lenovo M70/M90 Gen4 are equipped with ALC897, and they need
    ALC897_FIXUP_HEADSET_MIC_PIN quirk to make its headset mic work.
    The previous quirk for M70/M90 is for Gen3.
    
    Signed-off-by: Bin Li <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda: Add NVIDIA codec IDs a3 through a7 to patch table [+ + +]
Author: Nikhil Mahale <[email protected]>
Date:   Wed May 17 14:37:36 2023 +0530

    ALSA: hda: Add NVIDIA codec IDs a3 through a7 to patch table
    
    commit dc4f2ccaedddb489a83e7b12ebbdc347272aacc9 upstream.
    
    These IDs are for AD102, AD103, AD104, AD106, and AD107 gpus with
    audio functions that are largely similar to the existing ones.
    
    Tested audio using gnome-settings, over HDMI, DP-SST and DP-MST
    connections on AD106 gpu.
    
    Signed-off-by: Nikhil Mahale <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda: Fix Oops by 9.1 surround channel names [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue May 16 20:44:12 2023 +0200

    ALSA: hda: Fix Oops by 9.1 surround channel names
    
    commit 3b44ec8c5c44790a82f07e90db45643c762878c6 upstream.
    
    get_line_out_pfx() may trigger an Oops by overflowing the static array
    with more than 8 channels.  This was reported for MacBookPro 12,1 with
    Cirrus codec.
    
    As a workaround, extend for the 9.1 channels and also fix the
    potential Oops by unifying the code paths accessing the same array
    with the proper size check.
    
    Reported-by: Olliver Schinagl <[email protected]>
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ARM: 9296/1: HP Jornada 7XX: fix kernel-doc warnings [+ + +]
Author: Randy Dunlap <[email protected]>
Date:   Sun Apr 23 06:48:45 2023 +0100

    ARM: 9296/1: HP Jornada 7XX: fix kernel-doc warnings
    
    [ Upstream commit 46dd6078dbc7e363a8bb01209da67015a1538929 ]
    
    Fix kernel-doc warnings from the kernel test robot:
    
    jornada720_ssp.c:24: warning: Function parameter or member 'jornada_ssp_lock' not described in 'DEFINE_SPINLOCK'
    jornada720_ssp.c:24: warning: expecting prototype for arch/arm/mac(). Prototype was for DEFINE_SPINLOCK() instead
    jornada720_ssp.c:34: warning: Function parameter or member 'byte' not described in 'jornada_ssp_reverse'
    jornada720_ssp.c:57: warning: Function parameter or member 'byte' not described in 'jornada_ssp_byte'
    jornada720_ssp.c:85: warning: Function parameter or member 'byte' not described in 'jornada_ssp_inout'
    
    Link: lore.kernel.org/r/[email protected]
    
    Fixes: 69ebb22277a5 ("[ARM] 4506/1: HP Jornada 7XX: Addition of SSP Platform Driver")
    Signed-off-by: Randy Dunlap <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Kristoffer Ericson <[email protected]>
    Cc: [email protected]
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: fsl_micfil: register platform component before registering cpu dai [+ + +]
Author: Shengjiu Wang <[email protected]>
Date:   Fri Sep 3 18:30:04 2021 +0800

    ASoC: fsl_micfil: register platform component before registering cpu dai
    
    [ Upstream commit 0adf292069dcca8bab76a603251fcaabf77468ca ]
    
    There is no defer probe when adding platform component to
    snd_soc_pcm_runtime(rtd), the code is in snd_soc_add_pcm_runtime()
    
    snd_soc_register_card()
      -> snd_soc_bind_card()
        -> snd_soc_add_pcm_runtime()
          -> adding cpu dai
          -> adding codec dai
          -> adding platform component.
    
    So if the platform component is not ready at that time, then the
    sound card still registered successfully, but platform component
    is empty, the sound card can't be used.
    
    As there is defer probe checking for cpu dai component, then register
    platform component before cpu dai to avoid such issue.
    
    Fixes: 47a70e6fc9a8 ("ASoC: Add MICFIL SoC Digital Audio Interface driver.")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: Skylake: Fix declaration of enum skl_ch_cfg [+ + +]
Author: Cezary Rojewski <[email protected]>
Date:   Fri May 19 22:17:07 2023 +0200

    ASoC: Intel: Skylake: Fix declaration of enum skl_ch_cfg
    
    commit 95109657471311601b98e71f03d0244f48dc61bb upstream.
    
    Constant 'C4_CHANNEL' does not exist on the firmware side. Value 0xC is
    reserved for 'C7_1' instead.
    
    Fixes: 04afbbbb1cba ("ASoC: Intel: Skylake: Update the topology interface structure")
    Signed-off-by: Cezary Rojewski <[email protected]>
    Signed-off-by: Amadeusz Sławiński <amadeuszx.slawins[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Bluetooth: L2CAP: fix "bad unlock balance" in l2cap_disconnect_rsp [+ + +]
Author: Min Li <[email protected]>
Date:   Mon Apr 17 10:27:54 2023 +0800

    Bluetooth: L2CAP: fix "bad unlock balance" in l2cap_disconnect_rsp
    
    [ Upstream commit 25e97f7b1866e6b8503be349eeea44bb52d661ce ]
    
    conn->chan_lock isn't acquired before l2cap_get_chan_by_scid,
    if l2cap_get_chan_by_scid returns NULL, then 'bad unlock balance'
    is triggered.
    
    Reported-by: [email protected]
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Min Li <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: Fix mask generation for 32-bit narrow loads of 64-bit fields [+ + +]
Author: Will Deacon <[email protected]>
Date:   Thu May 18 11:25:28 2023 +0100

    bpf: Fix mask generation for 32-bit narrow loads of 64-bit fields
    
    commit 0613d8ca9ab382caabe9ed2dceb429e9781e443f upstream.
    
    A narrow load from a 64-bit context field results in a 64-bit load
    followed potentially by a 64-bit right-shift and then a bitwise AND
    operation to extract the relevant data.
    
    In the case of a 32-bit access, an immediate mask of 0xffffffff is used
    to construct a 64-bit BPP_AND operation which then sign-extends the mask
    value and effectively acts as a glorified no-op. For example:
    
    0:      61 10 00 00 00 00 00 00 r0 = *(u32 *)(r1 + 0)
    
    results in the following code generation for a 64-bit field:
    
            ldr     x7, [x7]        // 64-bit load
            mov     x10, #0xffffffffffffffff
            and     x7, x7, x10
    
    Fix the mask generation so that narrow loads always perform a 32-bit AND
    operation:
    
            ldr     x7, [x7]        // 64-bit load
            mov     w10, #0xffffffff
            and     w7, w7, w10
    
    Cc: Alexei Starovoitov <[email protected]>
    Cc: Daniel Borkmann <[email protected]>
    Cc: John Fastabend <[email protected]>
    Cc: Krzesimir Nowak <[email protected]>
    Cc: Andrey Ignatov <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
    Signed-off-by: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
btrfs: fix space cache inconsistency after error loading it from disk [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Thu May 4 12:04:18 2023 +0100

    btrfs: fix space cache inconsistency after error loading it from disk
    
    [ Upstream commit 0004ff15ea26015a0a3a6182dca3b9d1df32e2b7 ]
    
    When loading a free space cache from disk, at __load_free_space_cache(),
    if we fail to insert a bitmap entry, we still increment the number of
    total bitmaps in the btrfs_free_space_ctl structure, which is incorrect
    since we failed to add the bitmap entry. On error we then empty the
    cache by calling __btrfs_remove_free_space_cache(), which will result
    in getting the total bitmaps counter set to 1.
    
    A failure to load a free space cache is not critical, so if a failure
    happens we just rebuild the cache by scanning the extent tree, which
    happens at block-group.c:caching_thread(). Yet the failure will result
    in having the total bitmaps of the btrfs_free_space_ctl always bigger
    by 1 then the number of bitmap entries we have. So fix this by having
    the total bitmaps counter be incremented only if we successfully added
    the bitmap entry.
    
    Fixes: a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache")
    Reviewed-by: Anand Jain <[email protected]>
    CC: [email protected] # 4.4+
    Signed-off-by: Filipe Manana <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: replace calls to btrfs_find_free_ino with btrfs_find_free_objectid [+ + +]
Author: Nikolay Borisov <[email protected]>
Date:   Thu Nov 26 15:10:38 2020 +0200

    btrfs: replace calls to btrfs_find_free_ino with btrfs_find_free_objectid
    
    [ Upstream commit abadc1fcd72e887a8f875dabe4a07aa8c28ac8af ]
    
    The former is going away as part of the inode map removal so switch
    callers to btrfs_find_free_objectid. No functional changes since with
    INODE_MAP disabled (default) find_free_objectid was called anyway.
    
    Signed-off-by: Nikolay Borisov <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Stable-dep-of: 0004ff15ea26 ("btrfs: fix space cache inconsistency after error loading it from disk")
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: use nofs when cleaning up aborted transactions [+ + +]
Author: Josef Bacik <[email protected]>
Date:   Thu May 11 12:45:59 2023 -0400

    btrfs: use nofs when cleaning up aborted transactions
    
    commit 597441b3436a43011f31ce71dc0a6c0bf5ce958a upstream.
    
    Our CI system caught a lockdep splat:
    
      ======================================================
      WARNING: possible circular locking dependency detected
      6.3.0-rc7+ #1167 Not tainted
      ------------------------------------------------------
      kswapd0/46 is trying to acquire lock:
      ffff8c6543abd650 (sb_internal#2){++++}-{0:0}, at: btrfs_commit_inode_delayed_inode+0x5f/0x120
    
      but task is already holding lock:
      ffffffffabe61b40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x4aa/0x7a0
    
      which lock already depends on the new lock.
    
      the existing dependency chain (in reverse order) is:
    
      -> #1 (fs_reclaim){+.+.}-{0:0}:
             fs_reclaim_acquire+0xa5/0xe0
             kmem_cache_alloc+0x31/0x2c0
             alloc_extent_state+0x1d/0xd0
             __clear_extent_bit+0x2e0/0x4f0
             try_release_extent_mapping+0x216/0x280
             btrfs_release_folio+0x2e/0x90
             invalidate_inode_pages2_range+0x397/0x470
             btrfs_cleanup_dirty_bgs+0x9e/0x210
             btrfs_cleanup_one_transaction+0x22/0x760
             btrfs_commit_transaction+0x3b7/0x13a0
             create_subvol+0x59b/0x970
             btrfs_mksubvol+0x435/0x4f0
             __btrfs_ioctl_snap_create+0x11e/0x1b0
             btrfs_ioctl_snap_create_v2+0xbf/0x140
             btrfs_ioctl+0xa45/0x28f0
             __x64_sys_ioctl+0x88/0xc0
             do_syscall_64+0x38/0x90
             entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
      -> #0 (sb_internal#2){++++}-{0:0}:
             __lock_acquire+0x1435/0x21a0
             lock_acquire+0xc2/0x2b0
             start_transaction+0x401/0x730
             btrfs_commit_inode_delayed_inode+0x5f/0x120
             btrfs_evict_inode+0x292/0x3d0
             evict+0xcc/0x1d0
             inode_lru_isolate+0x14d/0x1e0
             __list_lru_walk_one+0xbe/0x1c0
             list_lru_walk_one+0x58/0x80
             prune_icache_sb+0x39/0x60
             super_cache_scan+0x161/0x1f0
             do_shrink_slab+0x163/0x340
             shrink_slab+0x1d3/0x290
             shrink_node+0x300/0x720
             balance_pgdat+0x35c/0x7a0
             kswapd+0x205/0x410
             kthread+0xf0/0x120
             ret_from_fork+0x29/0x50
    
      other info that might help us debug this:
    
       Possible unsafe locking scenario:
    
             CPU0                    CPU1
             ----                    ----
        lock(fs_reclaim);
                                     lock(sb_internal#2);
                                     lock(fs_reclaim);
        lock(sb_internal#2);
    
       *** DEADLOCK ***
    
      3 locks held by kswapd0/46:
       #0: ffffffffabe61b40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x4aa/0x7a0
       #1: ffffffffabe50270 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x113/0x290
       #2: ffff8c6543abd0e0 (&type->s_umount_key#44){++++}-{3:3}, at: super_cache_scan+0x38/0x1f0
    
      stack backtrace:
      CPU: 0 PID: 46 Comm: kswapd0 Not tainted 6.3.0-rc7+ #1167
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x58/0x90
       check_noncircular+0xd6/0x100
       ? save_trace+0x3f/0x310
       ? add_lock_to_list+0x97/0x120
       __lock_acquire+0x1435/0x21a0
       lock_acquire+0xc2/0x2b0
       ? btrfs_commit_inode_delayed_inode+0x5f/0x120
       start_transaction+0x401/0x730
       ? btrfs_commit_inode_delayed_inode+0x5f/0x120
       btrfs_commit_inode_delayed_inode+0x5f/0x120
       btrfs_evict_inode+0x292/0x3d0
       ? lock_release+0x134/0x270
       ? __pfx_wake_bit_function+0x10/0x10
       evict+0xcc/0x1d0
       inode_lru_isolate+0x14d/0x1e0
       __list_lru_walk_one+0xbe/0x1c0
       ? __pfx_inode_lru_isolate+0x10/0x10
       ? __pfx_inode_lru_isolate+0x10/0x10
       list_lru_walk_one+0x58/0x80
       prune_icache_sb+0x39/0x60
       super_cache_scan+0x161/0x1f0
       do_shrink_slab+0x163/0x340
       shrink_slab+0x1d3/0x290
       shrink_node+0x300/0x720
       balance_pgdat+0x35c/0x7a0
       kswapd+0x205/0x410
       ? __pfx_autoremove_wake_function+0x10/0x10
       ? __pfx_kswapd+0x10/0x10
       kthread+0xf0/0x120
       ? __pfx_kthread+0x10/0x10
       ret_from_fork+0x29/0x50
       </TASK>
    
    This happens because when we abort the transaction in the transaction
    commit path we call invalidate_inode_pages2_range on our block group
    cache inodes (if we have space cache v1) and any delalloc inodes we may
    have.  The plain invalidate_inode_pages2_range() call passes through
    GFP_KERNEL, which makes sense in most cases, but not here.  Wrap these
    two invalidate callees with memalloc_nofs_save/memalloc_nofs_restore to
    make sure we don't end up with the fs reclaim dependency under the
    transaction dependency.
    
    CC: [email protected] # 4.14+
    Signed-off-by: Josef Bacik <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
can: j1939: recvmsg(): allow MSG_CMSG_COMPAT flag [+ + +]
Author: Oliver Hartkopp <[email protected]>
Date:   Thu Apr 6 13:08:45 2023 +0200

    can: j1939: recvmsg(): allow MSG_CMSG_COMPAT flag
    
    commit 1db080cbdbab28752bbb1c86d64daf96253a5da1 upstream.
    
    The control message provided by J1939 support MSG_CMSG_COMPAT but
    blocked recvmsg() syscalls that have set this flag, i.e. on 32bit user
    space on 64 bit kernels.
    
    Link: https://github.com/hartkopp/can-isotp/issues/59
    Cc: Oleksij Rempel <[email protected]>
    Suggested-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Oliver Hartkopp <[email protected]>
    Tested-by: Oleksij Rempel <[email protected]>
    Acked-by: Oleksij Rempel <[email protected]>
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Link: https://lore.kernel.org/[email protected]
    Cc: [email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: kvaser_pciefd: Call request_irq() before enabling interrupts [+ + +]
Author: Jimmy Assarsson <[email protected]>
Date:   Tue May 16 15:43:15 2023 +0200

    can: kvaser_pciefd: Call request_irq() before enabling interrupts
    
    commit 84762d8da89d29ba842317eb842973e628c27391 upstream.
    
    Make sure the interrupt handler is registered before enabling interrupts.
    
    Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
    Cc: [email protected]
    Signed-off-by: Jimmy Assarsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: kvaser_pciefd: Clear listen-only bit if not explicitly requested [+ + +]
Author: Jimmy Assarsson <[email protected]>
Date:   Tue May 16 15:43:14 2023 +0200

    can: kvaser_pciefd: Clear listen-only bit if not explicitly requested
    
    commit bf7ac55e991ca177f1ac16be51152f1ef291a4df upstream.
    
    The listen-only bit was never cleared, causing the controller to
    always use listen-only mode, if previously set.
    
    Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
    Cc: [email protected]
    Signed-off-by: Jimmy Assarsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: kvaser_pciefd: Disable interrupts in probe error path [+ + +]
Author: Jimmy Assarsson <[email protected]>
Date:   Tue May 16 15:43:18 2023 +0200

    can: kvaser_pciefd: Disable interrupts in probe error path
    
    commit 11164bc39459335ab93c6e99d53b7e4292fba38b upstream.
    
    Disable interrupts in error path of probe function.
    
    Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
    Cc: [email protected]
    Signed-off-by: Jimmy Assarsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: kvaser_pciefd: Do not send EFLUSH command on TFD interrupt [+ + +]
Author: Jimmy Assarsson <[email protected]>
Date:   Tue May 16 15:43:17 2023 +0200

    can: kvaser_pciefd: Do not send EFLUSH command on TFD interrupt
    
    commit 262d7a52ba27525e3c1203230c9f0524e48bbb34 upstream.
    
    Under certain circumstances we send two EFLUSH commands, resulting in two
    EFLUSH ack packets, while only expecting a single EFLUSH ack.
    This can cause the driver Tx flush completion to get out of sync.
    
    To avoid this problem, don't enable the "Transmit buffer flush done" (TFD)
    interrupt and remove the code handling it.
    Now we only send EFLUSH command after receiving status packet with
    "Init detected" (IDET) bit set.
    
    Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
    Cc: [email protected]
    Signed-off-by: Jimmy Assarsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: kvaser_pciefd: Empty SRB buffer in probe [+ + +]
Author: Jimmy Assarsson <[email protected]>
Date:   Tue May 16 15:43:16 2023 +0200

    can: kvaser_pciefd: Empty SRB buffer in probe
    
    commit c589557dd1426f5adf90c7a919d4fde5a3e4ef64 upstream.
    
    Empty the "Shared receive buffer" (SRB) in probe, to assure we start in a
    known state, and don't process any irrelevant packets.
    
    Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
    Cc: [email protected]
    Signed-off-by: Jimmy Assarsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: kvaser_pciefd: Set CAN_STATE_STOPPED in kvaser_pciefd_stop() [+ + +]
Author: Jimmy Assarsson <[email protected]>
Date:   Tue May 16 15:43:13 2023 +0200

    can: kvaser_pciefd: Set CAN_STATE_STOPPED in kvaser_pciefd_stop()
    
    commit aed0e6ca7dbb8fbea9bc69c9ac663d5533c8c5d8 upstream.
    
    Set can.state to CAN_STATE_STOPPED in kvaser_pciefd_stop().
    Without this fix, wrong CAN state was repported after the interface was
    brought down.
    
    Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
    Cc: [email protected]
    Signed-off-by: Jimmy Assarsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cassini: Fix a memory leak in the error handling path of cas_init_one() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Mon May 15 21:09:11 2023 +0200

    cassini: Fix a memory leak in the error handling path of cas_init_one()
    
    [ Upstream commit 412cd77a2c24b191c65ea53025222418db09817c ]
    
    cas_saturn_firmware_init() allocates some memory using vmalloc(). This
    memory is freed in the .remove() function but not it the error handling
    path of the probe.
    
    Add the missing vfree() to avoid a memory leak, should an error occur.
    
    Fixes: fcaa40669cd7 ("cassini: use request_firmware")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Pavan Chebbi <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ceph: force updating the msg pointer in non-split case [+ + +]
Author: Xiubo Li <[email protected]>
Date:   Thu May 18 09:47:23 2023 +0800

    ceph: force updating the msg pointer in non-split case
    
    commit 4cafd0400bcb6187c0d4ab4d4b0229a89ac4f8c2 upstream.
    
    When the MClientSnap reqeust's op is not CEPH_SNAP_OP_SPLIT the
    request may still contain a list of 'split_realms', and we need
    to skip it anyway. Or it will be parsed as a corrupt snaptrace.
    
    Cc: [email protected]
    Link: https://tracker.ceph.com/issues/61200
    Reported-by: Frank Schilder <[email protected]>
    Signed-off-by: Xiubo Li <[email protected]>
    Reviewed-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
clk: tegra20: fix gcc-7 constant overflow warning [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Mon Feb 27 09:59:10 2023 +0100

    clk: tegra20: fix gcc-7 constant overflow warning
    
    [ Upstream commit b4a2adbf3586efa12fe78b9dec047423e01f3010 ]
    
    Older gcc versions get confused by comparing a u32 value to a negative
    constant in a switch()/case block:
    
    drivers/clk/tegra/clk-tegra20.c: In function 'tegra20_clk_measure_input_freq':
    drivers/clk/tegra/clk-tegra20.c:581:2: error: case label does not reduce to an integer constant
      case OSC_CTRL_OSC_FREQ_12MHZ:
      ^~~~
    drivers/clk/tegra/clk-tegra20.c:593:2: error: case label does not reduce to an integer constant
      case OSC_CTRL_OSC_FREQ_26MHZ:
    
    Make the constants unsigned instead.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: Fix signedness bug in tmc_etr_buf_insert_barrier_packet() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Apr 21 13:42:41 2023 +0300

    coresight: Fix signedness bug in tmc_etr_buf_insert_barrier_packet()
    
    commit f67bc15e526bb9920683ad6c1891ff9e08981335 upstream.
    
    This code generates a Smatch warning:
    
        drivers/hwtracing/coresight/coresight-tmc-etr.c:947 tmc_etr_buf_insert_barrier_packet()
        error: uninitialized symbol 'bufp'.
    
    The problem is that if tmc_sg_table_get_data() returns -EINVAL, then
    when we test if "len < CORESIGHT_BARRIER_PKT_SIZE", the negative "len"
    value is type promoted to a high unsigned long value which is greater
    than CORESIGHT_BARRIER_PKT_SIZE.  Fix this bug by adding an explicit
    check for error codes.
    
    Fixes: 75f4e3619fe2 ("coresight: tmc-etr: Add transparent buffer management")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Suzuki K Poulose <suzuki.pou[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cpupower: Make TSC read per CPU for Mperf monitor [+ + +]
Author: Wyes Karny <[email protected]>
Date:   Thu May 4 06:25:44 2023 +0000

    cpupower: Make TSC read per CPU for Mperf monitor
    
    [ Upstream commit c2adb1877b76fc81ae041e1db1a6ed2078c6746b ]
    
    System-wide TSC read could cause a drift in C0 percentage calculation.
    Because if first TSC is read and then one by one mperf is read for all
    cpus, this introduces drift between mperf reading of later CPUs and TSC
    reading.  To lower this drift read TSC per CPU and also just after mperf
    read.  This technique improves C0 percentage calculation in Mperf monitor.
    
    Before fix: (System 100% busy)
    
                  | Mperf              || RAPL        || Idle_Stats
     PKG|CORE| CPU| C0   | Cx   | Freq  || pack | core  || POLL | C1   | C2
       0|   0|   0| 87.15| 12.85|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   0| 256| 84.62| 15.38|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   1|   1| 87.15| 12.85|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   1| 257| 84.08| 15.92|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   2|   2| 86.61| 13.39|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   2| 258| 83.26| 16.74|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   3|   3| 86.61| 13.39|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   3| 259| 83.60| 16.40|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   4|   4| 86.33| 13.67|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   4| 260| 83.33| 16.67|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   5|   5| 86.06| 13.94|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   5| 261| 83.05| 16.95|  2695||168659003|3970468||  0.00|  0.00| 0.00
       0|   6|   6| 85.51| 14.49|  2695||168659003|3970468||  0.00|  0.00| 0.00
    
    After fix: (System 100% busy)
    
                 | Mperf              || RAPL        || Idle_Stats
     PKG|CORE| CPU| C0   | Cx   | Freq  || pack | core  || POLL | C1   | C2
       0|   0|   0| 98.03|  1.97|  2415||163295480|3811189||  0.00|  0.00| 0.00
       0|   0| 256| 98.50|  1.50|  2394||163295480|3811189||  0.00|  0.00| 0.00
       0|   1|   1| 99.99|  0.01|  2401||163295480|3811189||  0.00|  0.00| 0.00
       0|   1| 257| 99.99|  0.01|  2375||163295480|3811189||  0.00|  0.00| 0.00
       0|   2|   2| 99.99|  0.01|  2401||163295480|3811189||  0.00|  0.00| 0.00
       0|   2| 258|100.00|  0.00|  2401||163295480|3811189||  0.00|  0.00| 0.00
       0|   3|   3|100.00|  0.00|  2401||163295480|3811189||  0.00|  0.00| 0.00
       0|   3| 259| 99.99|  0.01|  2435||163295480|3811189||  0.00|  0.00| 0.00
       0|   4|   4|100.00|  0.00|  2401||163295480|3811189||  0.00|  0.00| 0.00
       0|   4| 260|100.00|  0.00|  2435||163295480|3811189||  0.00|  0.00| 0.00
       0|   5|   5| 99.99|  0.01|  2401||163295480|3811189||  0.00|  0.00| 0.00
       0|   5| 261|100.00|  0.00|  2435||163295480|3811189||  0.00|  0.00| 0.00
       0|   6|   6|100.00|  0.00|  2401||163295480|3811189||  0.00|  0.00| 0.00
       0|   6| 262|100.00|  0.00|  2435||163295480|3811189||  0.00|  0.00| 0.00
    
    Cc: Thomas Renninger <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Cc: Dominik Brodowski <[email protected]>
    
    Fixes: 7fe2f6399a84 ("cpupowerutils - cpufrequtils extended with quite some features")
    Signed-off-by: Wyes Karny <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
debugobjects: Don't wake up kswapd from fill_pool() [+ + +]
Author: Tetsuo Handa <[email protected]>
Date:   Thu May 11 22:47:32 2023 +0900

    debugobjects: Don't wake up kswapd from fill_pool()
    
    commit eb799279fb1f9c63c520fe8c1c41cb9154252db6 upstream.
    
    syzbot is reporting a lockdep warning in fill_pool() because the allocation
    from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)
    and therefore tries to wake up kswapd, which acquires kswapd_wait::lock.
    
    Since fill_pool() might be called with arbitrary locks held, fill_pool()
    should not assume that acquiring kswapd_wait::lock is safe.
    
    Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for
    !__GFP_DIRECT_RECLAIM allocation.
    
    Fixes: 3ac7fe5a4aab ("infrastructure to debug (dynamic) objects")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Tetsuo Handa <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=fe0c72f0ccbb93786380
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
driver core: add a helper to setup both the of_node and fwnode of a device [+ + +]
Author: Ioana Ciornei <[email protected]>
Date:   Thu Jun 17 15:29:04 2021 +0300

    driver core: add a helper to setup both the of_node and fwnode of a device
    
    [ Upstream commit 43e76d463c09a0272b84775bcc727c1eb8b384b2 ]
    
    There are many places where both the fwnode_handle and the of_node of a
    device need to be populated. Add a function which does both so that we
    have consistency.
    
    Suggested-by: Andrew Lunn <[email protected]>
    Signed-off-by: Ioana Ciornei <[email protected]>
    Reviewed-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: a26cc2934331 ("drm/mipi-dsi: Set the fwnode for mipi_dsi_device")
    Signed-off-by: Sasha Levin <[email protected]>
 
drm/amd/display: Use DC_LOG_DC in the trasform pixel function [+ + +]
Author: Rodrigo Siqueira <[email protected]>
Date:   Tue Nov 1 10:20:09 2022 -0400

    drm/amd/display: Use DC_LOG_DC in the trasform pixel function
    
    [ Upstream commit 7222f5841ff49709ca666b05ff336776e0664a20 ]
    
    [Why & How]
    DC now uses a new commit sequence which is more robust since it
    addresses cases where we need to reorganize pipes based on planes and
    other parameters. As a result, this new commit sequence reset the DC
    state by cleaning plane states and re-creating them accordingly with the
    need. For this reason, the dce_transform_set_pixel_storage_depth can be
    invoked after a plane state is destroyed and before its re-creation. In
    this situation and on DCE devices, DC will hit a condition that will
    trigger a dmesg log that looks like this:
    
    Console: switching to colour frame buffer device 240x67
    ------------[ cut here ]------------
    [..]
    Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 5603 07/28/2020
    RIP: 0010:dce_transform_set_pixel_storage_depth+0x3f8/0x480 [amdgpu]
    [..]
    RSP: 0018:ffffc9000202b850 EFLAGS: 00010293
    RAX: ffffffffa081d100 RBX: ffff888110790000 RCX: 000000000000000c
    RDX: ffff888100bedbf8 RSI: 0000000000001a50 RDI: ffff88810463c900
    RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000007
    R10: 0000000000000001 R11: 0000000000000f00 R12: ffff88810f500010
    R13: ffff888100bedbf8 R14: ffff88810f515688 R15: 0000000000000000
    FS:  00007ff0159249c0(0000) GS:ffff88840e940000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ff01528e550 CR3: 0000000002a10000 CR4: 00000000003506e0
    Call Trace:
     <TASK>
     ? dm_write_reg_func+0x21/0x80 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
     dc_stream_set_dither_option+0xfb/0x130 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
     amdgpu_dm_crtc_configure_crc_source+0x10b/0x190 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
     amdgpu_dm_atomic_commit_tail+0x20a8/0x2a90 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
     ? free_unref_page_commit+0x98/0x170
     ? free_unref_page+0xcc/0x150
     commit_tail+0x94/0x120
     drm_atomic_helper_commit+0x10f/0x140
     drm_atomic_commit+0x94/0xc0
     ? drm_plane_get_damage_clips.cold+0x1c/0x1c
     drm_client_modeset_commit_atomic+0x203/0x250
     drm_client_modeset_commit_locked+0x56/0x150
     drm_client_modeset_commit+0x21/0x40
     drm_fb_helper_lastclose+0x42/0x70
     amdgpu_driver_lastclose_kms+0xa/0x10 [amdgpu 340dadd3f7c8cf4be11cf0bdc850245e99abe0e8]
     drm_release+0xda/0x110
     __fput+0x89/0x240
     task_work_run+0x5c/0x90
     do_exit+0x333/0xae0
     do_group_exit+0x2d/0x90
     __x64_sys_exit_group+0x14/0x20
     do_syscall_64+0x5b/0x80
     ? exit_to_user_mode_prepare+0x1e/0x140
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7ff016ceaca1
    Code: Unable to access opcode bytes at RIP 0x7ff016ceac77.
    RSP: 002b:00007ffe7a2357e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 00007ff016e15a00 RCX: 00007ff016ceaca1
    RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
    RBP: 0000000000000000 R08: ffffffffffffff78 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007ff016e15a00
    R13: 0000000000000000 R14: 00007ff016e1aee8 R15: 00007ff016e1af00
     </TASK>
    
    Since this issue only happens in a transition state on DC, this commit
    replace BREAK_TO_DEBUGGER with DC_LOG_DC.
    
    Reviewed-by: Harry Wentland <[email protected]>
    Acked-by: Qingqing Zhuo <[email protected]>
    Signed-off-by: Rodrigo Siqueira <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/exynos: fix g2d_open/close helper function definitions [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Mon Apr 17 23:04:11 2023 +0200

    drm/exynos: fix g2d_open/close helper function definitions
    
    [ Upstream commit 2ef0785b30bd6549ddbc124979f1b6596e065ae2 ]
    
    The empty stub functions are defined as global functions, which
    causes a warning because of missing prototypes:
    
    drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: error: no previous prototype for 'g2d_open'
    drivers/gpu/drm/exynos/exynos_drm_g2d.h:42:5: error: no previous prototype for 'g2d_close'
    
    Mark them as 'static inline' to avoid the warning and to make
    them behave as intended.
    
    Fixes: eb4d9796fa34 ("drm/exynos: g2d: Convert to driver component API")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Inki Dae <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/mipi-dsi: Set the fwnode for mipi_dsi_device [+ + +]
Author: Saravana Kannan <[email protected]>
Date:   Thu Mar 9 22:39:09 2023 -0800

    drm/mipi-dsi: Set the fwnode for mipi_dsi_device
    
    [ Upstream commit a26cc2934331b57b5a7164bff344f0a2ec245fc0 ]
    
    After commit 3fb16866b51d ("driver core: fw_devlink: Make cycle
    detection more robust"), fw_devlink prints an error when consumer
    devices don't have their fwnode set. This used to be ignored silently.
    
    Set the fwnode mipi_dsi_device so fw_devlink can find them and properly
    track their dependencies.
    
    This fixes errors like this:
    [    0.334054] nwl-dsi 30a00000.mipi-dsi: Failed to create device link with regulator-lcd-1v8
    [    0.346964] nwl-dsi 30a00000.mipi-dsi: Failed to create device link with backlight-dsi
    
    Reported-by: Martin Kepplinger <[email protected]>
    Link: https://lore.kernel.org/lkml/[email protected]/
    Fixes: 068a00233969 ("drm: Add MIPI DSI bus support")
    Signed-off-by: Saravana Kannan <[email protected]>
    Tested-by: Martin Kepplinger <[email protected]>
    Link: https://lore.kernel.org/r/20230310[email protected]
    Signed-off-by: Maxime Ripard <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/tegra: Avoid potential 32-bit integer overflow [+ + +]
Author: Nur Hussein <[email protected]>
Date:   Thu Apr 6 04:25:59 2023 +0800

    drm/tegra: Avoid potential 32-bit integer overflow
    
    [ Upstream commit 2429b3c529da29d4277d519bd66d034842dcd70c ]
    
    In tegra_sor_compute_config(), the 32-bit value mode->clock is
    multiplied by 1000, and assigned to the u64 variable pclk. We can avoid
    a potential 32-bit integer overflow by casting mode->clock to u64 before
    we do the arithmetic and assignment.
    
    Signed-off-by: Nur Hussein <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
erspan: get the proto with the md version for collect_md [+ + +]
Author: Xin Long <[email protected]>
Date:   Thu May 11 19:22:11 2023 -0400

    erspan: get the proto with the md version for collect_md
    
    [ Upstream commit d80fc101d2eb9b3188c228d61223890aeea480a4 ]
    
    In commit 20704bd1633d ("erspan: build the header with the right proto
    according to erspan_ver"), it gets the proto with t->parms.erspan_ver,
    but t->parms.erspan_ver is not used by collect_md branch, and instead
    it should get the proto with md->version for collect_md.
    
    Thanks to Kevin for pointing this out.
    
    Fixes: 20704bd1633d ("erspan: build the header with the right proto according to erspan_ver")
    Fixes: 94d7d8f29287 ("ip6_gre: add erspan v2 support")
    Reported-by: Kevin Traynor <[email protected]>
    Signed-off-by: Xin Long <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: William Tu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ext2: Check block size validity during mount [+ + +]
Author: Jan Kara <[email protected]>
Date:   Wed Mar 1 11:59:39 2023 +0100

    ext2: Check block size validity during mount
    
    [ Upstream commit 62aeb94433fcec80241754b70d0d1836d5926b0a ]
    
    Check that log of block size stored in the superblock has sensible
    value. Otherwise the shift computing the block size can overflow leading
    to undefined behavior.
    
    Reported-by: [email protected]
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ext4: Fix best extent lstart adjustment logic in ext4_mb_new_inode_pa() [+ + +]
Author: Ojaswin Mujoo <[email protected]>
Date:   Sat Mar 25 13:43:39 2023 +0530

    ext4: Fix best extent lstart adjustment logic in ext4_mb_new_inode_pa()
    
    [ Upstream commit 93cdf49f6eca5e23f6546b8f28457b2e6a6961d9 ]
    
    When the length of best extent found is less than the length of goal extent
    we need to make sure that the best extent atleast covers the start of the
    original request. This is done by adjusting the ac_b_ex.fe_logical (logical
    start) of the extent.
    
    While doing so, the current logic sometimes results in the best extent's
    logical range overflowing the goal extent. Since this best extent is later
    added to the inode preallocation list, we have a possibility of introducing
    overlapping preallocations. This is discussed in detail here [1].
    
    As per Jan's suggestion, to fix this, replace the existing logic with the
    below logic for adjusting best extent as it keeps fragmentation in check
    while ensuring logical range of best extent doesn't overflow out of goal
    extent:
    
    1. Check if best extent can be kept at end of goal range and still cover
       original start.
    2. Else, check if best extent can be kept at start of goal range and still
       cover original start.
    3. Else, keep the best extent at start of original request.
    
    Also, add a few extra BUG_ONs that might help catch errors faster.
    
    [1] https://lore.kernel.org/r/[email protected]
    
    Suggested-by: Jan Kara <[email protected]>
    Signed-off-by: Ojaswin Mujoo <[email protected]>
    Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/f96aca6d415b36d1f90db86c1a8cd7e2e9d7ab0e.1679731817.git.ojaswin@linux.ibm.com
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: set goal start correctly in ext4_mb_normalize_request [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Sat Mar 4 01:21:01 2023 +0800

    ext4: set goal start correctly in ext4_mb_normalize_request
    
    [ Upstream commit b07ffe6927c75d99af534d685282ea188d9f71a6 ]
    
    We need to set ac_g_ex to notify the goal start used in
    ext4_mb_find_by_goal. Set ac_g_ex instead of ac_f_ex in
    ext4_mb_normalize_request.
    Besides we should assure goal start is in range [first_data_block,
    blocks_count) as ext4_mb_initialize_context does.
    
    [ Added a check to make sure size is less than ar->pright; otherwise
      we could end up passing an underflowed value of ar->pright - size to
      ext4_get_group_no_and_offset(), which will trigger a BUG_ON later on.
      - TYT ]
    
    Signed-off-by: Kemeng Shi <[email protected]>
    Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
    Link: https://lore.kernel.org/r/20230303172120.3800725-2-shikem[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
f2fs: fix to drop all dirty pages during umount() if cp_error is set [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Apr 10 10:12:22 2023 +0800

    f2fs: fix to drop all dirty pages during umount() if cp_error is set
    
    [ Upstream commit c9b3649a934d131151111354bcbb638076f03a30 ]
    
    xfstest generic/361 reports a bug as below:
    
    f2fs_bug_on(sbi, sbi->fsync_node_num);
    
    kernel BUG at fs/f2fs/super.c:1627!
    RIP: 0010:f2fs_put_super+0x3a8/0x3b0
    Call Trace:
     generic_shutdown_super+0x8c/0x1b0
     kill_block_super+0x2b/0x60
     kill_f2fs_super+0x87/0x110
     deactivate_locked_super+0x39/0x80
     deactivate_super+0x46/0x50
     cleanup_mnt+0x109/0x170
     __cleanup_mnt+0x16/0x20
     task_work_run+0x65/0xa0
     exit_to_user_mode_prepare+0x175/0x190
     syscall_exit_to_user_mode+0x25/0x50
     do_syscall_64+0x4c/0x90
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    During umount(), if cp_error is set, f2fs_wait_on_all_pages() should
    not stop waiting all F2FS_WB_CP_DATA pages to be writebacked, otherwise,
    fsync_node_num can be non-zero after f2fs_wait_on_all_pages() causing
    this bug.
    
    In this case, to avoid deadloop in f2fs_wait_on_all_pages(), it needs
    to drop all dirty pages rather than redirtying them.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev: udlfb: Fix endpoint check [+ + +]
Author: Alan Stern <[email protected]>
Date:   Fri May 19 15:32:30 2023 -0400

    fbdev: udlfb: Fix endpoint check
    
    commit ed9de4ed39875706607fb08118a58344ae6c5f42 upstream.
    
    The syzbot fuzzer detected a problem in the udlfb driver, caused by an
    endpoint not having the expected type:
    
    usb 1-1: Read EDID byte 0 failed: -71
    usb 1-1: Unable to get valid EDID from device/display
    ------------[ cut here ]------------
    usb 1-1: BOGUS urb xfer, pipe 3 != type 1
    WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880
    drivers/usb/core/urb.c:504
    Modules linked in:
    CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted
    6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
    04/28/2023
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
    ...
    Call Trace:
     <TASK>
     dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980
     dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315
     dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111
     dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743
    
    The current approach for this issue failed to catch the problem
    because it only checks for the existence of a bulk-OUT endpoint; it
    doesn't check whether this endpoint is the one that the driver will
    actually use.
    
    We can fix the problem by instead checking that the endpoint used by
    the driver does exist and is bulk-OUT.
    
    Reported-and-tested-by: [email protected]
    Signed-off-by: Alan Stern <[email protected]>
    CC: Pavel Skripkin <[email protected]>
    Fixes: aaf7dbe07385 ("video: fbdev: udlfb: properly check endpoint type")
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
firmware: arm_sdei: Fix sleep from invalid context BUG [+ + +]
Author: Pierre Gondois <[email protected]>
Date:   Thu Feb 16 09:49:19 2023 +0100

    firmware: arm_sdei: Fix sleep from invalid context BUG
    
    [ Upstream commit d2c48b2387eb89e0bf2a2e06e30987cf410acad4 ]
    
    Running a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altra
    triggers:
    
      BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
      in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0
      preempt_count: 0, expected: 0
      RCU nest depth: 0, expected: 0
      3 locks held by cpuhp/0/24:
        #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248
        #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248
        #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130
      irq event stamp: 36
      hardirqs last  enabled at (35): [<ffffda301e85b7bc>] finish_task_switch+0xb4/0x2b0
      hardirqs last disabled at (36): [<ffffda301e812fec>] cpuhp_thread_fun+0x21c/0x248
      softirqs last  enabled at (0): [<ffffda301e80b184>] copy_process+0x63c/0x1ac0
      softirqs last disabled at (0): [<0000000000000000>] 0x0
      CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...]
      Hardware name: WIWYNN Mt.Jade Server [...]
      Call trace:
        dump_backtrace+0x114/0x120
        show_stack+0x20/0x70
        dump_stack_lvl+0x9c/0xd8
        dump_stack+0x18/0x34
        __might_resched+0x188/0x228
        rt_spin_lock+0x70/0x120
        sdei_cpuhp_up+0x3c/0x130
        cpuhp_invoke_callback+0x250/0xf08
        cpuhp_thread_fun+0x120/0x248
        smpboot_thread_fn+0x280/0x320
        kthread+0x130/0x140
        ret_from_fork+0x10/0x20
    
    sdei_cpuhp_up() is called in the STARTING hotplug section,
    which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entry
    instead to execute the cpuhp cb later, with preemption enabled.
    
    SDEI originally got its own cpuhp slot to allow interacting
    with perf. It got superseded by pNMI and this early slot is not
    relevant anymore. [1]
    
    Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on the
    calling CPU. It is checked that preemption is disabled for them.
    _ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'.
    Preemption is enabled in those threads, but their cpumask is limited
    to 1 CPU.
    Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cb
    don't trigger them.
    
    Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI call
    which acts on the calling CPU.
    
    [1]:
    https://lore.kernel.org/all/[email protected]/
    
    Suggested-by: James Morse <[email protected]>
    Signed-off-by: Pierre Gondois <[email protected]>
    Reviewed-by: James Morse <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
forcedeth: Fix an error handling path in nv_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat May 20 10:30:17 2023 +0200

    forcedeth: Fix an error handling path in nv_probe()
    
    commit 5b17a4971d3b2a073f4078dd65331efbe35baa2d upstream.
    
    If an error occures after calling nv_mgmt_acquire_sema(), it should be
    undone with a corresponding nv_mgmt_release_sema() call.
    
    Add it in the error handling path of the probe as already done in the
    remove function.
    
    Fixes: cac1c52c3621 ("forcedeth: mgmt unit interface")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Acked-by: Zhu Yanjun <[email protected]>
    Link: https://lore.kernel.org/r/355e9a7d351b32ad897251b6f81b5886fcdc6766.1684571393.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode() [+ + +]
Author: Tetsuo Handa <[email protected]>
Date:   Tue Apr 11 19:57:33 2023 +0900

    fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode()
    
    [ Upstream commit 81b21c0f0138ff5a499eafc3eb0578ad2a99622c ]
    
    syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), for
    crafted filesystem image can contain bogus length. There conditions are
    not kernel bugs that can justify kernel to panic.
    
    Reported-by: syzbot <[email protected]>
    Link: https://syzkaller.appspot.com/bug?extid=e2787430e752a92b8750
    Reported-by: syzbot <[email protected]>
    Link: https://syzkaller.appspot.com/bug?extid=4913dca2ea6e4d43f3f1
    Signed-off-by: Tetsuo Handa <[email protected]>
    Reviewed-by: Viacheslav Dubeyko <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gfs2: Fix inode height consistency check [+ + +]
Author: Andreas Gruenbacher <[email protected]>
Date:   Tue Mar 28 00:43:16 2023 +0200

    gfs2: Fix inode height consistency check
    
    [ Upstream commit cfcdb5bad34f600aed7613c3c1a5e618111f77b7 ]
    
    The maximum allowed height of an inode's metadata tree depends on the
    filesystem block size; it is lower for bigger-block filesystems.  When
    reading in an inode, make sure that the height doesn't exceed the
    maximum allowed height.
    
    Arrays like sd_heightsize are sized to be big enough for any filesystem
    block size; they will often be slightly bigger than what's needed for a
    specific filesystem.
    
    Reported-by: [email protected]
    Signed-off-by: Andreas Gruenbacher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gpio: mockup: Fix mode of debugfs files [+ + +]
Author: Zev Weiss <[email protected]>
Date:   Tue May 16 22:47:56 2023 -0700

    gpio: mockup: Fix mode of debugfs files
    
    commit 0a1bb16e0fe6650c3841e611de374bfd5578ad70 upstream.
    
    This driver's debugfs files have had a read operation since commit
    2a9e27408e12 ("gpio: mockup: rework debugfs interface"), but were
    still being created with write-only mode bits.  Update them to
    indicate that the files can also be read.
    
    Signed-off-by: Zev Weiss <[email protected]>
    Fixes: 2a9e27408e12 ("gpio: mockup: rework debugfs interface")
    Cc: [email protected] # v5.1+
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
HID: logitech-hidpp: Don't use the USB serial for USB devices [+ + +]
Author: Bastien Nocera <[email protected]>
Date:   Thu Mar 2 14:01:16 2023 +0100

    HID: logitech-hidpp: Don't use the USB serial for USB devices
    
    [ Upstream commit 7ad1fe0da0fa91bf920b79ab05ae97bfabecc4f4 ]
    
    For devices that support the 0x0003 feature (Device Information) version 4,
    set the serial based on the output of that feature, rather than relying
    on the usbhid code setting the USB serial.
    
    This should allow the serial when connected through USB to (nearly)
    match the one when connected through a unifying receiver.
    
    For example, on the serials on a G903 wired/wireless mouse:
    - Unifying: 4067-e8-ce-cd-45
    - USB before patch: 017C385C3837
    - USB after patch: c086-e8-ce-cd-45
    
    Signed-off-by: Bastien Nocera <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: logitech-hidpp: Reconcile USB and Unifying serials [+ + +]
Author: Bastien Nocera <[email protected]>
Date:   Thu Mar 2 14:01:17 2023 +0100

    HID: logitech-hidpp: Reconcile USB and Unifying serials
    
    [ Upstream commit 5b3691d15e04b6d5a32c915577b8dbc5cfb56382 ]
    
    Now that USB HID++ devices can gather a serial number that matches the
    one that would be gathered when connected through a Unifying receiver,
    remove the last difference by dropping the product ID as devices
    usually have different product IDs when connected through USB or
    Unifying.
    
    For example, on the serials on a G903 wired/wireless mouse:
    - Unifying before patch: 4067-e8-ce-cd-45
    - USB before patch: c086-e8-ce-cd-45
    - Unifying and USB after patch: e8-ce-cd-45
    
    Signed-off-by: Bastien Nocera <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: wacom: Add new Intuos Pro Small (PTH-460) device IDs [+ + +]
Author: Ping Cheng <[email protected]>
Date:   Fri Aug 26 14:34:02 2022 -0700

    HID: wacom: Add new Intuos Pro Small (PTH-460) device IDs
    
    commit 0627f3df95e1609693f89e7ceb4156ac5db6e358 upstream.
    
    Add the new PIDs to wacom_wac.c to support the new model in the Intuos Pro series.
    
    Signed-off-by: Ping Cheng <[email protected]>
    Tested-by: Aaron Armstrong Skomra <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Cc: Ping Cheng <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: add three styli to wacom_intuos_get_tool_type [+ + +]
Author: Ping Cheng <[email protected]>
Date:   Wed Sep 28 13:49:29 2022 -0700

    HID: wacom: add three styli to wacom_intuos_get_tool_type
    
    commit bfdc750c4cb2f3461b9b00a2755e2145ac195c9a upstream.
    
    We forgot to add the 3D pen ID a year ago. There are two new pro pen
    IDs to be added.
    
    Signed-off-by: Ping Cheng <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: Force pen out of prox if no events have been received in a while [+ + +]
Author: Jason Gerecke <[email protected]>
Date:   Fri Jul 15 16:05:19 2022 -0700

    HID: wacom: Force pen out of prox if no events have been received in a while
    
    commit 94b179052f95c294d83e9c9c34f7833cf3cd4305 upstream.
    
    Prox-out events may not be reliably sent by some AES firmware. This can
    cause problems for users, particularly due to arbitration logic disabling
    touch input while the pen is in prox.
    
    This commit adds a timer which is reset every time a new prox event is
    received. When the timer expires we check to see if the pen is still in
    prox and force it out if necessary. This is patterend off of the same
    solution used by 'hid-letsketch' driver which has a similar problem.
    
    Link: https://github.com/linuxwacom/input-wacom/issues/310
    Signed-off-by: Jason Gerecke <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Cc: Ping Cheng <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: generic: Set battery quirk only when we see battery data [+ + +]
Author: Jason Gerecke <[email protected]>
Date:   Thu Apr 13 11:17:43 2023 -0700

    HID: wacom: generic: Set battery quirk only when we see battery data
    
    [ Upstream commit bea407a427baa019758f29f4d31b26f008bb8cc6 ]
    
    Some devices will include battery status usages in the HID descriptor
    but we won't see that battery data for one reason or another. For example,
    AES sensors won't send battery data unless an AES pen is in proximity.
    If a user does not have an AES pen but instead only interacts with the
    AES touchscreen with their fingers then there is no need for us to create
    a battery object. Similarly, if a family of peripherals shares the same
    HID descriptor between wired-only and wireless-capable SKUs, users of the
    former may never see a battery event and will not want a power_supply
    object created.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217062
    Link: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2354
    Signed-off-by: Jason Gerecke <[email protected]>
    Tested-by: Mario Limonciello <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
igb: fix bit_shift to be in [1..8] range [+ + +]
Author: Aleksandr Loktionov <[email protected]>
Date:   Tue May 16 10:41:46 2023 -0700

    igb: fix bit_shift to be in [1..8] range
    
    [ Upstream commit 60d758659f1fb49e0d5b6ac2691ede8c0958795b ]
    
    In igb_hash_mc_addr() the expression:
            "mc_addr[4] >> 8 - bit_shift", right shifting "mc_addr[4]"
    shift by more than 7 bits always yields zero, so hash becomes not so different.
    Add initialization with bit_shift = 1 and add a loop condition to ensure
    bit_shift will be always in [1..8] range.
    
    Fixes: 9d5c824399de ("igb: PCI-Express 82575 Gigabit Ethernet driver")
    Signed-off-by: Aleksandr Loktionov <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Input: xpad - add constants for GIP interface numbers [+ + +]
Author: Vicki Pfau <[email protected]>
Date:   Thu Apr 13 23:57:42 2023 -0700

    Input: xpad - add constants for GIP interface numbers
    
    [ Upstream commit f9b2e603c6216824e34dc9a67205d98ccc9a41ca ]
    
    Wired GIP devices present multiple interfaces with the same USB identification
    other than the interface number. This adds constants for differentiating two of
    them and uses them where appropriate
    
    Signed-off-by: Vicki Pfau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iommu/arm-smmu-v3: Acknowledge pri/event queue overflow if any [+ + +]
Author: Tomas Krcka <[email protected]>
Date:   Wed Mar 29 12:34:19 2023 +0000

    iommu/arm-smmu-v3: Acknowledge pri/event queue overflow if any
    
    [ Upstream commit 67ea0b7ce41844eae7c10bb04dfe66a23318c224 ]
    
    When an overflow occurs in the PRI queue, the SMMU toggles the overflow
    flag in the PROD register. To exit the overflow condition, the PRI thread
    is supposed to acknowledge it by toggling this flag in the CONS register.
    Unacknowledged overflow causes the queue to stop adding anything new.
    
    Currently, the priq thread always writes the CONS register back to the
    SMMU after clearing the queue.
    
    The writeback is not necessary if the OVFLG in the PROD register has not
    been changed, no overflow has occured.
    
    This commit checks the difference of the overflow flag between CONS and
    PROD register. If it's different, toggles the OVACKFLG flag in the CONS
    register and write it to the SMMU.
    
    The situation is similar for the event queue.
    The acknowledge register is also toggled after clearing the event
    queue but never propagated to the hardware. This would only be done the
    next time when executing evtq thread.
    
    Unacknowledged event queue overflow doesn't affect the event
    queue, because the SMMU still adds elements to that queue when the
    overflow condition is active.
    But it feel nicer to keep SMMU in sync when possible, so use the same
    way here as well.
    
    Signed-off-by: Tomas Krcka <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ip6_gre: Fix skb_under_panic in __gre6_xmit() [+ + +]
Author: Peilin Ye <[email protected]>
Date:   Thu Apr 14 13:35:40 2022 -0700

    ip6_gre: Fix skb_under_panic in __gre6_xmit()
    
    [ Upstream commit ab198e1d0dd8dc4bc7575fb50758e2cbd51e14e1 ]
    
    Feng reported an skb_under_panic BUG triggered by running
    test_ip6gretap() in tools/testing/selftests/bpf/test_tunnel.sh:
    
    [   82.492551] skbuff: skb_under_panic: text:ffffffffb268bb8e len:403 put:12 head:ffff9997c5480000 data:ffff9997c547fff8 tail:0x18b end:0x2c0 dev:ip6gretap11
    <...>
    [   82.607380] Call Trace:
    [   82.609389]  <TASK>
    [   82.611136]  skb_push.cold.109+0x10/0x10
    [   82.614289]  __gre6_xmit+0x41e/0x590
    [   82.617169]  ip6gre_tunnel_xmit+0x344/0x3f0
    [   82.620526]  dev_hard_start_xmit+0xf1/0x330
    [   82.623882]  sch_direct_xmit+0xe4/0x250
    [   82.626961]  __dev_queue_xmit+0x720/0xfe0
    <...>
    [   82.633431]  packet_sendmsg+0x96a/0x1cb0
    [   82.636568]  sock_sendmsg+0x30/0x40
    <...>
    
    The following sequence of events caused the BUG:
    
    1. During ip6gretap device initialization, tunnel->tun_hlen (e.g. 4) is
       calculated based on old flags (see ip6gre_calc_hlen());
    2. packet_snd() reserves header room for skb A, assuming
       tunnel->tun_hlen is 4;
    3. Later (in clsact Qdisc), the eBPF program sets a new tunnel key for
       skb A using bpf_skb_set_tunnel_key() (see _ip6gretap_set_tunnel());
    4. __gre6_xmit() detects the new tunnel key, and recalculates
       "tun_hlen" (e.g. 12) based on new flags (e.g. TUNNEL_KEY and
       TUNNEL_SEQ);
    5. gre_build_header() calls skb_push() with insufficient reserved header
       room, triggering the BUG.
    
    As sugguested by Cong, fix it by moving the call to skb_cow_head() after
    the recalculation of tun_hlen.
    
    Reproducer:
    
      OBJ=$LINUX/tools/testing/selftests/bpf/test_tunnel_kern.o
    
      ip netns add at_ns0
      ip link add veth0 type veth peer name veth1
      ip link set veth0 netns at_ns0
      ip netns exec at_ns0 ip addr add 172.16.1.100/24 dev veth0
      ip netns exec at_ns0 ip link set dev veth0 up
      ip link set dev veth1 up mtu 1500
      ip addr add dev veth1 172.16.1.200/24
    
      ip netns exec at_ns0 ip addr add ::11/96 dev veth0
      ip netns exec at_ns0 ip link set dev veth0 up
      ip addr add dev veth1 ::22/96
      ip link set dev veth1 up
    
      ip netns exec at_ns0 \
            ip link add dev ip6gretap00 type ip6gretap seq flowlabel 0xbcdef key 2 \
            local ::11 remote ::22
    
      ip netns exec at_ns0 ip addr add dev ip6gretap00 10.1.1.100/24
      ip netns exec at_ns0 ip addr add dev ip6gretap00 fc80::100/96
      ip netns exec at_ns0 ip link set dev ip6gretap00 up
    
      ip link add dev ip6gretap11 type ip6gretap external
      ip addr add dev ip6gretap11 10.1.1.200/24
      ip addr add dev ip6gretap11 fc80::200/24
      ip link set dev ip6gretap11 up
    
      tc qdisc add dev ip6gretap11 clsact
      tc filter add dev ip6gretap11 egress bpf da obj $OBJ sec ip6gretap_set_tunnel
      tc filter add dev ip6gretap11 ingress bpf da obj $OBJ sec ip6gretap_get_tunnel
    
      ping6 -c 3 -w 10 -q ::11
    
    Fixes: 6712abc168eb ("ip6_gre: add ip6 gre and gretap collect_md mode")
    Reported-by: Feng Zhou <[email protected]>
    Co-developed-by: Cong Wang <[email protected]>
    Signed-off-by: Cong Wang <[email protected]>
    Signed-off-by: Peilin Ye <[email protected]>
    Signed-off-by: David S. Miller <dav[email protected]>
    Stable-dep-of: d80fc101d2eb ("erspan: get the proto with the md version for collect_md")
    Signed-off-by: Sasha Levin <[email protected]>

ip6_gre: Make o_seqno start from 0 in native mode [+ + +]
Author: Peilin Ye <[email protected]>
Date:   Thu Apr 21 15:08:38 2022 -0700

    ip6_gre: Make o_seqno start from 0 in native mode
    
    [ Upstream commit fde98ae91f79cab4e020f40c35ed23cbdc59661c ]
    
    For IP6GRE and IP6GRETAP devices, currently o_seqno starts from 1 in
    native mode.  According to RFC 2890 2.2., "The first datagram is sent
    with a sequence number of 0."  Fix it.
    
    It is worth mentioning that o_seqno already starts from 0 in collect_md
    mode, see the "if (tunnel->parms.collect_md)" clause in __gre6_xmit(),
    where tunnel->o_seqno is passed to gre_build_header() before getting
    incremented.
    
    Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
    Signed-off-by: Peilin Ye <[email protected]>
    Acked-by: William Tu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: d80fc101d2eb ("erspan: get the proto with the md version for collect_md")
    Signed-off-by: Sasha Levin <[email protected]>

 
ip_gre, ip6_gre: Fix race condition on o_seqno in collect_md mode [+ + +]
Author: Peilin Ye <[email protected]>
Date:   Thu Apr 21 15:09:02 2022 -0700

    ip_gre, ip6_gre: Fix race condition on o_seqno in collect_md mode
    
    [ Upstream commit 31c417c948d7f6909cb63f0ac3298f3c38f8ce20 ]
    
    As pointed out by Jakub Kicinski, currently using TUNNEL_SEQ in
    collect_md mode is racy for [IP6]GRE[TAP] devices.  Consider the
    following sequence of events:
    
    1. An [IP6]GRE[TAP] device is created in collect_md mode using "ip link
       add ... external".  "ip" ignores "[o]seq" if "external" is specified,
       so TUNNEL_SEQ is off, and the device is marked as NETIF_F_LLTX (i.e.
       it uses lockless TX);
    2. Someone sets TUNNEL_SEQ on outgoing skb's, using e.g.
       bpf_skb_set_tunnel_key() in an eBPF program attached to this device;
    3. gre_fb_xmit() or __gre6_xmit() processes these skb's:
    
            gre_build_header(skb, tun_hlen,
                             flags, protocol,
                             tunnel_id_to_key32(tun_info->key.tun_id),
                             (flags & TUNNEL_SEQ) ? htonl(tunnel->o_seqno++)
                                                  : 0);   ^^^^^^^^^^^^^^^^^
    
    Since we are not using the TX lock (&txq->_xmit_lock), multiple CPUs may
    try to do this tunnel->o_seqno++ in parallel, which is racy.  Fix it by
    making o_seqno atomic_t.
    
    As mentioned by Eric Dumazet in commit b790e01aee74 ("ip_gre: lockless
    xmit"), making o_seqno atomic_t increases "chance for packets being out
    of order at receiver" when NETIF_F_LLTX is on.
    
    Maybe a better fix would be:
    
    1. Do not ignore "oseq" in external mode.  Users MUST specify "oseq" if
       they want the kernel to allow sequencing of outgoing packets;
    2. Reject all outgoing TUNNEL_SEQ packets if the device was not created
       with "oseq".
    
    Unfortunately, that would break userspace.
    
    We could now make [IP6]GRE[TAP] devices always NETIF_F_LLTX, but let us
    do it in separate patches to keep this fix minimal.
    
    Suggested-by: Jakub Kicinski <[email protected]>
    Fixes: 77a5196a804e ("gre: add sequence number for collect md mode.")
    Signed-off-by: Peilin Ye <[email protected]>
    Acked-by: William Tu <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: d80fc101d2eb ("erspan: get the proto with the md version for collect_md")
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv6: Fix out-of-bounds access in ipv6_find_tlv() [+ + +]
Author: Gavrilov Ilia <[email protected]>
Date:   Tue May 23 08:29:44 2023 +0000

    ipv6: Fix out-of-bounds access in ipv6_find_tlv()
    
    commit 878ecb0897f4737a4c9401f3523fd49589025671 upstream.
    
    optlen is fetched without checking whether there is more than one byte to parse.
    It can lead to out-of-bounds access.
    
    Found by InfoTeCS on behalf of Linux Verification Center
    (linuxtesting.org) with SVACE.
    
    Fixes: c61a40432509 ("[IPV6]: Find option offset by type.")
    Signed-off-by: Gavrilov Ilia <[email protected]>
    Reviewed-by: Jiri Pirko <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: ipvlan:Fix out-of-bounds caused by unclear skb->cb [+ + +]
Author: t.feng <[email protected]>
Date:   Wed May 10 11:50:44 2023 +0800

    ipvlan:Fix out-of-bounds caused by unclear skb->cb
    
    [ Upstream commit 90cbed5247439a966b645b34eb0a2e037836ea8e ]
    
    If skb enqueue the qdisc, fq_skb_cb(skb)->time_to_send is changed which
    is actually skb->cb, and IPCB(skb_in)->opt will be used in
    __ip_options_echo. It is possible that memcpy is out of bounds and lead
    to stack overflow.
    We should clear skb->cb before ip_local_out or ip6_local_out.
    
    v2:
    1. clean the stack info
    2. use IPCB/IP6CB instead of skb->cb
    
    crash on stable-5.10(reproduce in kasan kernel).
    Stack info:
    [ 2203.651571] BUG: KASAN: stack-out-of-bounds in
    __ip_options_echo+0x589/0x800
    [ 2203.653327] Write of size 4 at addr ffff88811a388f27 by task
    swapper/3/0
    [ 2203.655460] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted
    5.10.0-60.18.0.50.h856.kasan.eulerosv2r11.x86_64 #1
    [ 2203.655466] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS rel-1.10.2-0-g5f4c7b1-20181220_000000-szxrtosci10000 04/01/2014
    [ 2203.655475] Call Trace:
    [ 2203.655481]  <IRQ>
    [ 2203.655501]  dump_stack+0x9c/0xd3
    [ 2203.655514]  print_address_description.constprop.0+0x19/0x170
    [ 2203.655530]  __kasan_report.cold+0x6c/0x84
    [ 2203.655586]  kasan_report+0x3a/0x50
    [ 2203.655594]  check_memory_region+0xfd/0x1f0
    [ 2203.655601]  memcpy+0x39/0x60
    [ 2203.655608]  __ip_options_echo+0x589/0x800
    [ 2203.655654]  __icmp_send+0x59a/0x960
    [ 2203.655755]  nf_send_unreach+0x129/0x3d0 [nf_reject_ipv4]
    [ 2203.655763]  reject_tg+0x77/0x1bf [ipt_REJECT]
    [ 2203.655772]  ipt_do_table+0x691/0xa40 [ip_tables]
    [ 2203.655821]  nf_hook_slow+0x69/0x100
    [ 2203.655828]  __ip_local_out+0x21e/0x2b0
    [ 2203.655857]  ip_local_out+0x28/0x90
    [ 2203.655868]  ipvlan_process_v4_outbound+0x21e/0x260 [ipvlan]
    [ 2203.655931]  ipvlan_xmit_mode_l3+0x3bd/0x400 [ipvlan]
    [ 2203.655967]  ipvlan_queue_xmit+0xb3/0x190 [ipvlan]
    [ 2203.655977]  ipvlan_start_xmit+0x2e/0xb0 [ipvlan]
    [ 2203.655984]  xmit_one.constprop.0+0xe1/0x280
    [ 2203.655992]  dev_hard_start_xmit+0x62/0x100
    [ 2203.656000]  sch_direct_xmit+0x215/0x640
    [ 2203.656028]  __qdisc_run+0x153/0x1f0
    [ 2203.656069]  __dev_queue_xmit+0x77f/0x1030
    [ 2203.656173]  ip_finish_output2+0x59b/0xc20
    [ 2203.656244]  __ip_finish_output.part.0+0x318/0x3d0
    [ 2203.656312]  ip_finish_output+0x168/0x190
    [ 2203.656320]  ip_output+0x12d/0x220
    [ 2203.656357]  __ip_queue_xmit+0x392/0x880
    [ 2203.656380]  __tcp_transmit_skb+0x1088/0x11c0
    [ 2203.656436]  __tcp_retransmit_skb+0x475/0xa30
    [ 2203.656505]  tcp_retransmit_skb+0x2d/0x190
    [ 2203.656512]  tcp_retransmit_timer+0x3af/0x9a0
    [ 2203.656519]  tcp_write_timer_handler+0x3ba/0x510
    [ 2203.656529]  tcp_write_timer+0x55/0x180
    [ 2203.656542]  call_timer_fn+0x3f/0x1d0
    [ 2203.656555]  expire_timers+0x160/0x200
    [ 2203.656562]  run_timer_softirq+0x1f4/0x480
    [ 2203.656606]  __do_softirq+0xfd/0x402
    [ 2203.656613]  asm_call_irq_on_stack+0x12/0x20
    [ 2203.656617]  </IRQ>
    [ 2203.656623]  do_softirq_own_stack+0x37/0x50
    [ 2203.656631]  irq_exit_rcu+0x134/0x1a0
    [ 2203.656639]  sysvec_apic_timer_interrupt+0x36/0x80
    [ 2203.656646]  asm_sysvec_apic_timer_interrupt+0x12/0x20
    [ 2203.656654] RIP: 0010:default_idle+0x13/0x20
    [ 2203.656663] Code: 89 f0 5d 41 5c 41 5d 41 5e c3 cc cc cc cc cc cc cc
    cc cc cc cc cc cc 0f 1f 44 00 00 0f 1f 44 00 00 0f 00 2d 9f 32 57 00 fb
    f4 <c3> cc cc cc cc 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 be 08
    [ 2203.656668] RSP: 0018:ffff88810036fe78 EFLAGS: 00000256
    [ 2203.656676] RAX: ffffffffaf2a87f0 RBX: ffff888100360000 RCX:
    ffffffffaf290191
    [ 2203.656681] RDX: 0000000000098b5e RSI: 0000000000000004 RDI:
    ffff88811a3c4f60
    [ 2203.656686] RBP: 0000000000000000 R08: 0000000000000001 R09:
    ffff88811a3c4f63
    [ 2203.656690] R10: ffffed10234789ec R11: 0000000000000001 R12:
    0000000000000003
    [ 2203.656695] R13: ffff888100360000 R14: 0000000000000000 R15:
    0000000000000000
    [ 2203.656729]  default_idle_call+0x5a/0x150
    [ 2203.656735]  cpuidle_idle_call+0x1c6/0x220
    [ 2203.656780]  do_idle+0xab/0x100
    [ 2203.656786]  cpu_startup_entry+0x19/0x20
    [ 2203.656793]  secondary_startup_64_no_verify+0xc2/0xcb
    
    [ 2203.657409] The buggy address belongs to the page:
    [ 2203.658648] page:0000000027a9842f refcount:1 mapcount:0
    mapping:0000000000000000 index:0x0 pfn:0x11a388
    [ 2203.658665] flags:
    0x17ffffc0001000(reserved|node=0|zone=2|lastcpupid=0x1fffff)
    [ 2203.658675] raw: 0017ffffc0001000 ffffea000468e208 ffffea000468e208
    0000000000000000
    [ 2203.658682] raw: 0000000000000000 0000000000000000 00000001ffffffff
    0000000000000000
    [ 2203.658686] page dumped because: kasan: bad access detected
    
    To reproduce(ipvlan with IPVLAN_MODE_L3):
    Env setting:
    =======================================================
    modprobe ipvlan ipvlan_default_mode=1
    sysctl net.ipv4.conf.eth0.forwarding=1
    iptables -t nat -A POSTROUTING -s 20.0.0.0/255.255.255.0 -o eth0 -j
    MASQUERADE
    ip link add gw link eth0 type ipvlan
    ip -4 addr add 20.0.0.254/24 dev gw
    ip netns add net1
    ip link add ipv1 link eth0 type ipvlan
    ip link set ipv1 netns net1
    ip netns exec net1 ip link set ipv1 up
    ip netns exec net1 ip -4 addr add 20.0.0.4/24 dev ipv1
    ip netns exec net1 route add default gw 20.0.0.254
    ip netns exec net1 tc qdisc add dev ipv1 root netem loss 10%
    ifconfig gw up
    iptables -t filter -A OUTPUT -p tcp --dport 8888 -j REJECT --reject-with
    icmp-port-unreachable
    =======================================================
    And then excute the shell(curl any address of eth0 can reach):
    
    for((i=1;i<=100000;i++))
    do
            ip netns exec net1 curl x.x.x.x:8888
    done
    =======================================================
    
    Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
    Signed-off-by: "t.feng" <[email protected]>
    Suggested-by: Florian Westphal <[email protected]>
    Reviewed-by: Paolo Abeni <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: x86: do not report a vCPU as preempted outside instruction boundaries [+ + +]
Author: Paolo Bonzini <[email protected]>
Date:   Tue Jun 7 10:09:03 2022 -0400

    KVM: x86: do not report a vCPU as preempted outside instruction boundaries
    
    commit 6cd88243c7e03845a450795e134b488fc2afb736 upstream.
    
    If a vCPU is outside guest mode and is scheduled out, it might be in the
    process of making a memory access.  A problem occurs if another vCPU uses
    the PV TLB flush feature during the period when the vCPU is scheduled
    out, and a virtual address has already been translated but has not yet
    been accessed, because this is equivalent to using a stale TLB entry.
    
    To avoid this, only report a vCPU as preempted if sure that the guest
    is at an instruction boundary.  A rescheduling request will be delivered
    to the host physical CPU as an external interrupt, so for simplicity
    consider any vmexit *not* instruction boundary except for external
    interrupts.
    
    It would in principle be okay to report the vCPU as preempted also
    if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the
    vmentry/vmexit overhead unnecessarily, and optimistic spinning is
    also unlikely to succeed.  However, leave it for later because right
    now kvm_vcpu_check_block() is doing memory accesses.  Even
    though the TLB flush issue only applies to virtual memory address,
    it's very much preferrable to be conservative.
    
    Reported-by: Jann Horn <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    [OP: use VCPU_STAT() for debugfs entries]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
lib/string_helpers: Introduce string_upper() and string_lower() helpers [+ + +]
Author: Vadim Pasternak <[email protected]>
Date:   Tue Jul 14 15:01:53 2020 +0300

    lib/string_helpers: Introduce string_upper() and string_lower() helpers
    
    [ Upstream commit 58eeba0bdb52afe5c18ce2a760ca9fe2901943e9 ]
    
    Provide the helpers for string conversions to upper and lower cases.
    
    Signed-off-by: Vadim Pasternak <[email protected]>
    Signed-off-by: Andy Shevchenko <[email protected]>
    Stable-dep-of: 3c0f4f09c063 ("usb: gadget: u_ether: Fix host MAC address case")
    Signed-off-by: Sasha Levin <[email protected]>

 
lib: cpu_rmap: Avoid use after free on rmap->obj array entries [+ + +]
Author: Eli Cohen <[email protected]>
Date:   Wed Feb 8 07:51:02 2023 +0200

    lib: cpu_rmap: Avoid use after free on rmap->obj array entries
    
    [ Upstream commit 4e0473f1060aa49621d40a113afde24818101d37 ]
    
    When calling irq_set_affinity_notifier() with NULL at the notify
    argument, it will cause freeing of the glue pointer in the
    corresponding array entry but will leave the pointer in the array. A
    subsequent call to free_irq_cpu_rmap() will try to free this entry again
    leading to possible use after free.
    
    Fix that by setting NULL to the array entry and checking that we have
    non-zero at the array entry when iterating over the array in
    free_irq_cpu_rmap().
    
    The current code does not suffer from this since there are no cases
    where irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the
    notify arg) is called, followed by a call to free_irq_cpu_rmap() so we
    don't hit and issue. Subsequent patches in this series excersize this
    flow, hence the required fix.
    
    Cc: Thomas Gleixner <[email protected]>
    Signed-off-by: Eli Cohen <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 5.4.244 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue May 30 12:44:11 2023 +0100

    Linux 5.4.244
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Harshit Mogalapalli <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
linux/dim: Do nothing if no time delta between samples [+ + +]
Author: Roy Novich <[email protected]>
Date:   Sun May 7 16:57:43 2023 +0300

    linux/dim: Do nothing if no time delta between samples
    
    [ Upstream commit 162bd18eb55adf464a0fa2b4144b8d61c75ff7c2 ]
    
    Add return value for dim_calc_stats. This is an indication for the
    caller if curr_stats was assigned by the function. Avoid using
    curr_stats uninitialized over {rdma/net}_dim, when no time delta between
    samples. Coverity reported this potential use of an uninitialized
    variable.
    
    Fixes: 4c4dbb4a7363 ("net/mlx5e: Move dynamic interrupt coalescing code to include/linux")
    Fixes: cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
    Signed-off-by: Roy Novich <[email protected]>
    Reviewed-by: Aya Levin <[email protected]>
    Reviewed-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Reviewed-by: Michal Kubiak <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
m68k: Move signal frame following exception on 68020/030 [+ + +]
Author: Finn Thain <[email protected]>
Date:   Sat May 6 19:38:12 2023 +1000

    m68k: Move signal frame following exception on 68020/030
    
    commit b845b574f86dcb6a70dfa698aa87a237b0878d2a upstream.
    
    On 68030/020, an instruction such as, moveml %a2-%a3/%a5,%sp@- may cause
    a stack page fault during instruction execution (i.e. not at an
    instruction boundary) and produce a format 0xB exception frame.
    
    In this situation, the value of USP will be unreliable.  If a signal is
    to be delivered following the exception, this USP value is used to
    calculate the location for a signal frame.  This can result in a
    corrupted user stack.
    
    The corruption was detected in dash (actually in glibc) where it showed
    up as an intermittent "stack smashing detected" message and crash
    following signal delivery for SIGCHLD.
    
    It was hard to reproduce that failure because delivery of the signal
    raced with the page fault and because the kernel places an unpredictable
    gap of up to 7 bytes between the USP and the signal frame.
    
    A format 0xB exception frame can be produced by a bus error or an
    address error.  The 68030 Users Manual says that address errors occur
    immediately upon detection during instruction prefetch.  The instruction
    pipeline allows prefetch to overlap with other instructions, which means
    an address error can arise during the execution of a different
    instruction.  So it seems likely that this patch may help in the address
    error case also.
    
    Reported-and-tested-by: Stan Johnson <[email protected]>
    Link: https://lore.kernel.org/all/CAMuHMdW3yD22_ApemzW_6me3adq6A458u1_F0v-1EYwK_62jPA@mail.gmail.com/
    Cc: Michael Schmitz <[email protected]>
    Cc: Andreas Schwab <[email protected]>
    Cc: [email protected]
    Co-developed-by: Michael Schmitz <[email protected]>
    Signed-off-by: Michael Schmitz <[email protected]>
    Signed-off-by: Finn Thain <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/9e66262a754fcba50208aa424188896cc52a1dd1.1683365892.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mcb-pci: Reallocate memory region to avoid memory overlapping [+ + +]
Author: Rodríguez Barbarin, José Javier <[email protected]>
Date:   Tue Apr 11 10:33:28 2023 +0200

    mcb-pci: Reallocate memory region to avoid memory overlapping
    
    [ Upstream commit 9be24faadd085c284890c3afcec7a0184642315a ]
    
    mcb-pci requests a fixed-size memory region to parse the chameleon
    table, however, if the chameleon table is smaller that the allocated
    region, it could overlap with the IP Cores' memory regions.
    
    After parsing the chameleon table, drop/reallocate the memory region
    with the actual chameleon table size.
    
    Co-developed-by: Jorge Sanjuan Garcia <[email protected]>
    Signed-off-by: Jorge Sanjuan Garcia <[email protected]>
    Signed-off-by: Javier Rodriguez <[email protected]>
    Signed-off-by: Johannes Thumshirn <[email protected]>
    Link: https://lore.kernel.org/r/20230411083329.4506-3-jth@kernel.org
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
media: netup_unidvb: fix use-after-free at del_timer() [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Wed Mar 8 12:55:14 2023 +0000

    media: netup_unidvb: fix use-after-free at del_timer()
    
    [ Upstream commit 0f5bb36bf9b39a2a96e730bf4455095b50713f63 ]
    
    When Universal DVB card is detaching, netup_unidvb_dma_fini()
    uses del_timer() to stop dma->timeout timer. But when timer
    handler netup_unidvb_dma_timeout() is running, del_timer()
    could not stop it. As a result, the use-after-free bug could
    happen. The process is shown below:
    
        (cleanup routine)          |        (timer routine)
                                   | mod_timer(&dev->tx_sim_timer, ..)
    netup_unidvb_finidev()         | (wait a time)
      netup_unidvb_dma_fini()      | netup_unidvb_dma_timeout()
        del_timer(&dma->timeout);  |
                                   |   ndev->pci_dev->dev //USE
    
    Fix by changing del_timer() to del_timer_sync().
    
    Link: https://lore.kernel.org/linux-media/[email protected]
    Fixes: 52b1eaf4c59a ("[media] netup_unidvb: NetUP Universal DVB-S/S2/T/T2/C PCI-E card driver")
    Signed-off-by: Duoming Zhou <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: radio-shark: Add endpoint checks [+ + +]
Author: Alan Stern <[email protected]>
Date:   Mon Apr 10 15:40:05 2023 -0400

    media: radio-shark: Add endpoint checks
    
    commit 76e31045ba030e94e72105c01b2e98f543d175ac upstream.
    
    The syzbot fuzzer was able to provoke a WARNING from the radio-shark2
    driver:
    
    ------------[ cut here ]------------
    usb 1-1: BOGUS urb xfer, pipe 1 != type 3
    WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
    Modules linked in:
    CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504
    Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7
    RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
    RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac
    RBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000
    R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001
    R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200
    FS:  0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
     usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387
     shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88
    ...
    
    The problem was caused by the fact that the driver does not check
    whether the endpoints it uses are actually present and have the
    appropriate types.  This can be fixed by adding a simple check of
    these endpoints (and similarly for the radio-shark driver).
    
    Link: https://syzkaller.appspot.com/bug?extid=4b3f8190f6e13b3efd74
    Reported-and-tested-by: [email protected]
    Signed-off-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
memstick: r592: Fix UAF bug in r592_remove due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Wed Mar 8 00:43:38 2023 +0800

    memstick: r592: Fix UAF bug in r592_remove due to race condition
    
    [ Upstream commit 63264422785021704c39b38f65a78ab9e4a186d7 ]
    
    In r592_probe, dev->detect_timer was bound with r592_detect_timer.
    In r592_irq function, the timer function will be invoked by mod_timer.
    
    If we remove the module which will call hantro_release to make cleanup,
    there may be a unfinished work. The possible sequence is as follows,
    which will cause a typical UAF bug.
    
    Fix it by canceling the work before cleanup in r592_remove.
    
    CPU0                  CPU1
    
                        |r592_detect_timer
    r592_remove         |
      memstick_free_host|
      put_device;       |
      kfree(host);      |
                        |
                        | queue_work
                        |   &host->media_checker //use
    
    Signed-off-by: Zheng Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mfd: dln2: Fix memory leak in dln2_probe() [+ + +]
Author: Qiang Ning <[email protected]>
Date:   Thu Mar 30 10:43:53 2023 +0800

    mfd: dln2: Fix memory leak in dln2_probe()
    
    [ Upstream commit 96da8f148396329ba769246cb8ceaa35f1ddfc48 ]
    
    When dln2_setup_rx_urbs() in dln2_probe() fails, error out_free forgets
    to call usb_put_dev() to decrease the refcount of dln2->usb_dev.
    
    Fix this by adding usb_put_dev() in the error handling code of
    dln2_probe().
    
    Signed-off-by: Qiang Ning <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
mt76: mt7615: Fix build with older compilers [+ + +]
Author: Pablo Greco <[email protected]>
Date:   Sun Dec 1 15:17:10 2019 -0300

    mt76: mt7615: Fix build with older compilers
    
    commit f53300fdaa84dc02f96ab9446b5bac4d20016c43 upstream.
    
    Some compilers (tested with 4.8.5 from CentOS 7) fail properly process
    FIELD_GET inside an inline function, which ends up in a BUILD_BUG_ON.
    Convert inline function to a macro.
    
    Fixes commit bf92e7685100 ("mt76: mt7615: add support for per-chain
    signal strength reporting")
    Reported in https://lkml.org/lkml/2019/9/21/146
    
    Reported-by: kbuild test robot <[email protected]>
    Signed-off-by: Pablo Greco <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Cc: Vegard Nossum <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/mlx5: Devcom, fix error flow in mlx5_devcom_register_device [+ + +]
Author: Shay Drory <[email protected]>
Date:   Tue May 2 13:35:11 2023 +0300

    net/mlx5: Devcom, fix error flow in mlx5_devcom_register_device
    
    commit af87194352cad882d787d06fb7efa714acd95427 upstream.
    
    In case devcom allocation is failed, mlx5 is always freeing the priv.
    However, this priv might have been allocated by a different thread,
    and freeing it might lead to use-after-free bugs.
    Fix it by freeing the priv only in case it was allocated by the
    running thread.
    
    Fixes: fadd59fc50d0 ("net/mlx5: Introduce inter-device communication mechanism")
    Signed-off-by: Shay Drory <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net/mlx5: Fix error message when failing to allocate device memory [+ + +]
Author: Roi Dayan <[email protected]>
Date:   Mon May 1 14:37:56 2023 +0300

    net/mlx5: Fix error message when failing to allocate device memory
    
    commit a65735148e0328f80c0f72f9f8d2f609bfcf4aff upstream.
    
    Fix spacing for the error and also the correct error code pointer.
    
    Fixes: c9b9dcb430b3 ("net/mlx5: Move device memory management to mlx5_core")
    Signed-off-by: Roi Dayan <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net: add vlan_get_protocol_and_depth() helper [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue May 9 13:18:57 2023 +0000

    net: add vlan_get_protocol_and_depth() helper
    
    [ Upstream commit 4063384ef762cc5946fc7a3f89879e76c6ec51e2 ]
    
    Before blamed commit, pskb_may_pull() was used instead
    of skb_header_pointer() in __vlan_get_protocol() and friends.
    
    Few callers depended on skb->head being populated with MAC header,
    syzbot caught one of them (skb_mac_gso_segment())
    
    Add vlan_get_protocol_and_depth() to make the intent clearer
    and use it where sensible.
    
    This is a more generic fix than commit e9d3f80935b6
    ("net/af_packet: make sure to pull mac header") which was
    dealing with a similar issue.
    
    kernel BUG at include/linux/skbuff.h:2655 !
    invalid opcode: 0000 [#1] SMP KASAN
    CPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
    RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]
    RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136
    Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
    RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286
    RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9
    R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012
    R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7
    FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    [<ffffffff847018dd>] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419
    [<ffffffff8470398a>] skb_gso_segment include/linux/netdevice.h:4819 [inline]
    [<ffffffff8470398a>] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725
    [<ffffffff84707042>] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313
    [<ffffffff851a9ec7>] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029
    [<ffffffff851b4a82>] packet_snd net/packet/af_packet.c:3111 [inline]
    [<ffffffff851b4a82>] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142
    [<ffffffff84669a12>] sock_sendmsg_nosec net/socket.c:716 [inline]
    [<ffffffff84669a12>] sock_sendmsg net/socket.c:736 [inline]
    [<ffffffff84669a12>] __sys_sendto+0x472/0x5f0 net/socket.c:2139
    [<ffffffff84669c75>] __do_sys_sendto net/socket.c:2151 [inline]
    [<ffffffff84669c75>] __se_sys_sendto net/socket.c:2147 [inline]
    [<ffffffff84669c75>] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147
    [<ffffffff8551d40f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<ffffffff8551d40f>] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80
    [<ffffffff85600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: 469aceddfa3e ("vlan: consolidate VLAN parsing code and limit max parsing depth")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Toke Høiland-Jørgensen <[email protected]>
    Cc: Willem de Bruijn <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: annotate sk->sk_err write from do_recvmmsg() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue May 9 16:35:53 2023 +0000

    net: annotate sk->sk_err write from do_recvmmsg()
    
    [ Upstream commit e05a5f510f26607616fecdd4ac136310c8bea56b ]
    
    do_recvmmsg() can write to sk->sk_err from multiple threads.
    
    As said before, many other points reading or writing sk_err
    need annotations.
    
    Fixes: 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: syzbot <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop() [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Thu May 4 16:07:27 2023 -0700

    net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()
    
    [ Upstream commit 93e0401e0fc0c54b0ac05b687cd135c2ac38187c ]
    
    The call to phy_stop() races with the later call to phy_disconnect(),
    resulting in concurrent phy_suspend() calls being run from different
    CPUs. The final call to phy_disconnect() ensures that the PHY is
    stopped and suspended, too.
    
    Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine")
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: bcmgenet: Restore phy_stop() depending upon suspend/close [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Sun May 14 19:56:07 2023 -0700

    net: bcmgenet: Restore phy_stop() depending upon suspend/close
    
    [ Upstream commit 225c657945c4a6307741cb3cc89467eadcc26e9b ]
    
    Removing the phy_stop() from bcmgenet_netif_stop() ended up causing
    warnings from the PHY library that phy_start() is called from the
    RUNNING state since we are no longer stopping the PHY state machine
    during bcmgenet_suspend().
    
    Restore the call to phy_stop() but make it conditional on being called
    from the close or suspend path.
    
    Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine")
    Fixes: 93e0401e0fc0 ("net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()")
    Signed-off-by: Florian Fainelli <[email protected]>
    Reviewed-by: Pavan Chebbi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: Catch invalid index in XPS mapping [+ + +]
Author: Nick Child <[email protected]>
Date:   Tue Mar 21 10:07:24 2023 -0500

    net: Catch invalid index in XPS mapping
    
    [ Upstream commit 5dd0dfd55baec0742ba8f5625a0dd064aca7db16 ]
    
    When setting the XPS value of a TX queue, warn the user once if the
    index of the queue is greater than the number of allocated TX queues.
    
    Previously, this scenario went uncaught. In the best case, it resulted
    in unnecessary allocations. In the worst case, it resulted in
    out-of-bounds memory references through calls to `netdev_get_tx_queue(
    dev, index)`. Therefore, it is important to inform the user but not
    worth returning an error and risk downing the netdevice.
    
    Signed-off-by: Nick Child <[email protected]>
    Reviewed-by: Piotr Raczynski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: datagram: fix data-races in datagram_poll() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue May 9 17:31:31 2023 +0000

    net: datagram: fix data-races in datagram_poll()
    
    [ Upstream commit 5bca1d081f44c9443e61841842ce4e9179d327b6 ]
    
    datagram_poll() runs locklessly, we should add READ_ONCE()
    annotations while reading sk->sk_err, sk->sk_shutdown and sk->sk_state.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: fec: Better handle pm_runtime_get() failing in .remove() [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Wed May 10 22:00:20 2023 +0200

    net: fec: Better handle pm_runtime_get() failing in .remove()
    
    [ Upstream commit f816b9829b19394d318e01953aa3b2721bca040d ]
    
    In the (unlikely) event that pm_runtime_get() (disguised as
    pm_runtime_resume_and_get()) fails, the remove callback returned an
    error early. The problem with this is that the driver core ignores the
    error value and continues removing the device. This results in a
    resource leak. Worse the devm allocated resources are freed and so if a
    callback of the driver is called later the register mapping is already
    gone which probably results in a crash.
    
    Fixes: a31eda65ba21 ("net: fec: fix clock count mis-match")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: Fix load-tearing on sk->sk_stamp in sock_recv_cmsgs(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Mon May 8 10:55:43 2023 -0700

    net: Fix load-tearing on sk->sk_stamp in sock_recv_cmsgs().
    
    [ Upstream commit dfd9248c071a3710c24365897459538551cb7167 ]
    
    KCSAN found a data race in sock_recv_cmsgs() where the read access
    to sk->sk_stamp needs READ_ONCE().
    
    BUG: KCSAN: data-race in packet_recvmsg / packet_recvmsg
    
    write (marked) to 0xffff88803c81f258 of 8 bytes by task 19171 on cpu 0:
     sock_write_timestamp include/net/sock.h:2670 [inline]
     sock_recv_cmsgs include/net/sock.h:2722 [inline]
     packet_recvmsg+0xb97/0xd00 net/packet/af_packet.c:3489
     sock_recvmsg_nosec net/socket.c:1019 [inline]
     sock_recvmsg+0x11a/0x130 net/socket.c:1040
     sock_read_iter+0x176/0x220 net/socket.c:1118
     call_read_iter include/linux/fs.h:1845 [inline]
     new_sync_read fs/read_write.c:389 [inline]
     vfs_read+0x5e0/0x630 fs/read_write.c:470
     ksys_read+0x163/0x1a0 fs/read_write.c:613
     __do_sys_read fs/read_write.c:623 [inline]
     __se_sys_read fs/read_write.c:621 [inline]
     __x64_sys_read+0x41/0x50 fs/read_write.c:621
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    read to 0xffff88803c81f258 of 8 bytes by task 19183 on cpu 1:
     sock_recv_cmsgs include/net/sock.h:2721 [inline]
     packet_recvmsg+0xb64/0xd00 net/packet/af_packet.c:3489
     sock_recvmsg_nosec net/socket.c:1019 [inline]
     sock_recvmsg+0x11a/0x130 net/socket.c:1040
     sock_read_iter+0x176/0x220 net/socket.c:1118
     call_read_iter include/linux/fs.h:1845 [inline]
     new_sync_read fs/read_write.c:389 [inline]
     vfs_read+0x5e0/0x630 fs/read_write.c:470
     ksys_read+0x163/0x1a0 fs/read_write.c:613
     __do_sys_read fs/read_write.c:623 [inline]
     __se_sys_read fs/read_write.c:621 [inline]
     __x64_sys_read+0x41/0x50 fs/read_write.c:621
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    value changed: 0xffffffffc4653600 -> 0x0000000000000000
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 19183 Comm: syz-executor.5 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    
    Fixes: 6c7c98bad488 ("sock: avoid dirtying sk_stamp, if possible")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: fix skb leak in __skb_tstamp_tx() [+ + +]
Author: Pratyush Yadav <[email protected]>
Date:   Mon May 22 17:30:20 2023 +0200

    net: fix skb leak in __skb_tstamp_tx()
    
    commit 8a02fb71d7192ff1a9a47c9d937624966c6e09af upstream.
    
    Commit 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs with
    TX timestamp.") added a call to skb_orphan_frags_rx() to fix leaks with
    zerocopy skbs. But it ended up adding a leak of its own. When
    skb_orphan_frags_rx() fails, the function just returns, leaking the skb
    it just cloned. Free it before returning.
    
    This bug was discovered and resolved using Coverity Static Analysis
    Security Testing (SAST) by Synopsys, Inc.
    
    Fixes: 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.")
    Signed-off-by: Pratyush Yadav <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: fix stack overflow when LRO is disabled for virtual interfaces [+ + +]
Author: Taehee Yoo <[email protected]>
Date:   Wed May 17 14:30:10 2023 +0000

    net: fix stack overflow when LRO is disabled for virtual interfaces
    
    commit ae9b15fbe63447bc1d3bba3769f409d17ca6fdf6 upstream.
    
    When the virtual interface's feature is updated, it synchronizes the
    updated feature for its own lower interface.
    This propagation logic should be worked as the iteration, not recursively.
    But it works recursively due to the netdev notification unexpectedly.
    This problem occurs when it disables LRO only for the team and bonding
    interface type.
    
           team0
             |
      +------+------+-----+-----+
      |      |      |     |     |
    team1  team2  team3  ...  team200
    
    If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGE
    event to its own lower interfaces(team1 ~ team200).
    It is worked by netdev_sync_lower_features().
    So, the NETDEV_FEAT_CHANGE notification logic of each lower interface
    work iteratively.
    But generated NETDEV_FEAT_CHANGE event is also sent to the upper
    interface too.
    upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own
    lower interfaces again.
    lower and upper interfaces receive this event and generate this
    event again and again.
    So, the stack overflow occurs.
    
    But it is not the infinite loop issue.
    Because the netdev_sync_lower_features() updates features before
    generating the NETDEV_FEAT_CHANGE event.
    Already synchronized lower interfaces skip notification logic.
    So, it is just the problem that iteration logic is changed to the
    recursive unexpectedly due to the notification mechanism.
    
    Reproducer:
    
    ip link add team0 type team
    ethtool -K team0 lro on
    for i in {1..200}
    do
            ip link add team$i master team0 type team
            ethtool -K team$i lro on
    done
    
    ethtool -K team0 lro off
    
    In order to fix it, the notifier_ctx member of bonding/team is introduced.
    
    Reported-by: [email protected]
    Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack")
    Signed-off-by: Taehee Yoo <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: Nikolay Aleksandrov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: hns3: fix reset delay time to avoid configuration timeout [+ + +]
Author: Jie Wang <[email protected]>
Date:   Fri May 12 18:00:13 2023 +0800

    net: hns3: fix reset delay time to avoid configuration timeout
    
    [ Upstream commit 814d0c786068e858d889ada3153bff82f64223ad ]
    
    Currently the hns3 vf function reset delays 5000ms before vf rebuild
    process. In product applications, this delay is too long for application
    configurations and causes configuration timeout.
    
    According to the tests, 500ms delay is enough for reset process except PF
    FLR. So this patch modifies delay to 500ms in these scenarios.
    
    Fixes: 6988eb2a9b77 ("net: hns3: Add support to reset the enet/ring mgmt layer")
    Signed-off-by: Jie Wang <[email protected]>
    Signed-off-by: Hao Lan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hns3: fix sending pfc frames after reset issue [+ + +]
Author: Jijie Shao <[email protected]>
Date:   Fri May 12 18:00:12 2023 +0800

    net: hns3: fix sending pfc frames after reset issue
    
    [ Upstream commit f14db07064727dd3bc0906c77a6d2759c1bbb395 ]
    
    To prevent the system from abnormally sending PFC frames after an
    abnormal reset. The hns3 driver notifies the firmware to disable pfc
    before reset.
    
    Fixes: 35d93a30040c ("net: hns3: adjust the process of PF reset")
    Signed-off-by: Jijie Shao <[email protected]>
    Signed-off-by: Hao Lan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: nsh: Use correct mac_offset to unwind gso skb in nsh_gso_segment() [+ + +]
Author: Dong Chenchen <[email protected]>
Date:   Thu May 11 20:54:40 2023 +0800

    net: nsh: Use correct mac_offset to unwind gso skb in nsh_gso_segment()
    
    [ Upstream commit c83b49383b595be50647f0c764a48c78b5f3c4f8 ]
    
    As the call trace shows, skb_panic was caused by wrong skb->mac_header
    in nsh_gso_segment():
    
    invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
    CPU: 3 PID: 2737 Comm: syz Not tainted 6.3.0-next-20230505 #1
    RIP: 0010:skb_panic+0xda/0xe0
    call Trace:
     skb_push+0x91/0xa0
     nsh_gso_segment+0x4f3/0x570
     skb_mac_gso_segment+0x19e/0x270
     __skb_gso_segment+0x1e8/0x3c0
     validate_xmit_skb+0x452/0x890
     validate_xmit_skb_list+0x99/0xd0
     sch_direct_xmit+0x294/0x7c0
     __dev_queue_xmit+0x16f0/0x1d70
     packet_xmit+0x185/0x210
     packet_snd+0xc15/0x1170
     packet_sendmsg+0x7b/0xa0
     sock_sendmsg+0x14f/0x160
    
    The root cause is:
    nsh_gso_segment() use skb->network_header - nhoff to reset mac_header
    in skb_gso_error_unwind() if inner-layer protocol gso fails.
    However, skb->network_header may be reset by inner-layer protocol
    gso function e.g. mpls_gso_segment. skb->mac_header reset by the
    inaccurate network_header will be larger than skb headroom.
    
    nsh_gso_segment
        nhoff = skb->network_header - skb->mac_header;
        __skb_pull(skb,nsh_len)
        skb_mac_gso_segment
            mpls_gso_segment
                skb_reset_network_header(skb);//skb->network_header+=nsh_len
                return -EINVAL;
        skb_gso_error_unwind
            skb_push(skb, nsh_len);
            skb->mac_header = skb->network_header - nhoff;
            // skb->mac_header > skb->headroom, cause skb_push panic
    
    Use correct mac_offset to restore mac_header and get rid of nhoff.
    
    Fixes: c411ed854584 ("nsh: add GSO support")
    Reported-by: [email protected]
    Suggested-by: Eric Dumazet <[email protected]>
    Signed-off-by: Dong Chenchen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: pasemi: Fix return type of pasemi_mac_start_tx() [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Sun Mar 19 16:41:08 2023 -0700

    net: pasemi: Fix return type of pasemi_mac_start_tx()
    
    [ Upstream commit c8384d4a51e7cb0e6587f3143f29099f202c5de1 ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    warning in clang aims to catch these at compile time, which reveals:
    
      drivers/net/ethernet/pasemi/pasemi_mac.c:1665:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .ndo_start_xmit         = pasemi_mac_start_tx,
                                        ^~~~~~~~~~~~~~~~~~~
      1 error generated.
    
    ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
    'netdev_tx_t', not 'int'. Adjust the return type of
    pasemi_mac_start_tx() to match the prototype's to resolve the warning.
    While PowerPC does not currently implement support for kCFI, it could in
    the future, which means this warning becomes a fatal CFI failure at run
    time.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Signed-off-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Horatiu Vultur <h[email protected]>
    Link: https://lore.kernel.org/r/20230319-pasemi-incompatible-pointer-types-strict-v1-1-1b9459d8aef0@kernel.org
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: tap: check vlan with eth_type_vlan() method [+ + +]
Author: Menglong Dong <[email protected]>
Date:   Thu Jan 14 18:32:38 2021 -0800

    net: tap: check vlan with eth_type_vlan() method
    
    [ Upstream commit b69df2608281b71575fbb3b9f426dbcc4be8a700 ]
    
    Replace some checks for ETH_P_8021Q and ETH_P_8021AD in
    drivers/net/tap.c with eth_type_vlan.
    
    Signed-off-by: Menglong Dong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 4063384ef762 ("net: add vlan_get_protocol_and_depth() helper")
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: conntrack: fix possible bug_on with enable_hooks=1 [+ + +]
Author: Florian Westphal <[email protected]>
Date:   Thu May 4 14:55:02 2023 +0200

    netfilter: conntrack: fix possible bug_on with enable_hooks=1
    
    [ Upstream commit e72eeab542dbf4f544e389e64fa13b82a1b6d003 ]
    
    I received a bug report (no reproducer so far) where we trip over
    
    712         rcu_read_lock();
    713         ct_hook = rcu_dereference(nf_ct_hook);
    714         BUG_ON(ct_hook == NULL);  // here
    
    In nf_conntrack_destroy().
    
    First turn this BUG_ON into a WARN.  I think it was triggered
    via enable_hooks=1 flag.
    
    When this flag is turned on, the conntrack hooks are registered
    before nf_ct_hook pointer gets assigned.
    This opens a short window where packets enter the conntrack machinery,
    can have skb->_nfct set up and a subsequent kfree_skb might occur
    before nf_ct_hook is set.
    
    Call nf_conntrack_init_end() to set nf_ct_hook before we register the
    pernet ops.
    
    Fixes: ba3fbe663635 ("netfilter: nf_conntrack: provide modparam to always register conntrack hooks")
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: add nft_setelem_parse_key() [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 16 16:44:31 2023 +0200

    netfilter: nf_tables: add nft_setelem_parse_key()
    
    [ 20a1452c35425b2cef76f21f8395ef069dfddfa9 ]
    
    Add helper function to parse the set element key netlink attribute.
    
    v4: No changes
    v3: New patch
    
    [sbrivio: refactor error paths and labels; use NFT_DATA_VALUE_MAXLEN
      instead of sizeof(*key) in helper, value can be longer than that;
      rebase]
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: allow up to 64 bytes in the set element data area [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 16 16:44:32 2023 +0200

    netfilter: nf_tables: allow up to 64 bytes in the set element data area
    
    [ fdb9c405e35bdc6e305b9b4e20ebc141ed14fc81 ]
    
    So far, the set elements could store up to 128-bits in the data area.
    
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: hold mutex on netns pre_exit path [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 16 16:44:35 2023 +0200

    netfilter: nf_tables: hold mutex on netns pre_exit path
    
    [ 3923b1e4406680d57da7e873da77b1683035d83f ]
    
    clean_net() runs in workqueue while walking over the lists, grab mutex.
    
    Fixes: 767d1216bff8 ("netfilter: nftables: fix possible UAF over chains from packet path in netns")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: stricter validation of element data [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 16 16:44:33 2023 +0200

    netfilter: nf_tables: stricter validation of element data
    
    [ 7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6 ]
    
    Make sure element data type and length do not mismatch the one specified
    by the set declaration.
    
    Fixes: 7d7402642eaf ("netfilter: nf_tables: variable sized set element keys / data")
    Reported-by: Hugues ANGUELKOV <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: validate NFTA_SET_ELEM_OBJREF based on NFT_SET_OBJECT flag [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 16 16:44:34 2023 +0200

    netfilter: nf_tables: validate NFTA_SET_ELEM_OBJREF based on NFT_SET_OBJECT flag
    
    [ 5a2f3dc31811e93be15522d9eb13ed61460b76c8 ]
    
    If the NFTA_SET_ELEM_OBJREF netlink attribute is present and
    NFT_SET_OBJECT flag is set on, report EINVAL.
    
    Move existing sanity check earlier to validate that NFT_SET_OBJECT
    requires NFTA_SET_ELEM_OBJREF.
    
    Fixes: 8aeff920dcc9 ("netfilter: nf_tables: add stateful object reference to set elements")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: validate registers coming from userspace. [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 16 16:44:30 2023 +0200

    netfilter: nf_tables: validate registers coming from userspace.
    
    [ 6e1acfa387b9ff82cfc7db8cc3b6959221a95851 ]
    
    Bail out in case userspace uses unsupported registers.
    
    Fixes: 49499c3e6e18 ("netfilter: nf_tables: switch registers to 32 bit addressing")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nftables: add nft_parse_register_load() and use it [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 16 16:44:27 2023 +0200

    netfilter: nftables: add nft_parse_register_load() and use it
    
    [ 4f16d25c68ec844299a4df6ecbb0234eaf88a935 ]
    
    This new function combines the netlink register attribute parser
    and the load validation function.
    
    This update requires to replace:
    
            enum nft_registers      sreg:8;
    
    in many of the expression private areas otherwise compiler complains
    with:
    
            error: cannot take address of bit-field ‘sreg’
    
    when passing the register field as reference.
    
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nftables: add nft_parse_register_store() and use it [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 16 16:44:28 2023 +0200

    netfilter: nftables: add nft_parse_register_store() and use it
    
    [ 345023b0db315648ccc3c1a36aee88304a8b4d91 ]
    
    This new function combines the netlink register attribute parser
    and the store validation function.
    
    This update requires to replace:
    
            enum nft_registers      dreg:8;
    
    in many of the expression private areas otherwise compiler complains
    with:
    
            error: cannot take address of bit-field ‘dreg’
    
    when passing the register field as reference.
    
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nftables: statify nft_parse_register() [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 16 16:44:29 2023 +0200

    netfilter: nftables: statify nft_parse_register()
    
    [ 08a01c11a5bb3de9b0a9c9b2685867e50eda9910 ]
    
    This function is not used anymore by any extension, statify it.
    
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netlink: annotate accesses to nlk->cb_running [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue May 9 16:56:34 2023 +0000

    netlink: annotate accesses to nlk->cb_running
    
    [ Upstream commit a939d14919b799e6fff8a9c80296ca229ba2f8a4 ]
    
    Both netlink_recvmsg() and netlink_native_seq_show() read
    nlk->cb_running locklessly. Use READ_ONCE() there.
    
    Add corresponding WRITE_ONCE() to netlink_dump() and
    __netlink_dump_start()
    
    syzbot reported:
    BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsg
    
    write to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0:
    __netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399
    netlink_dump_start include/linux/netlink.h:308 [inline]
    rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130
    netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577
    rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192
    netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
    netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365
    netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942
    sock_sendmsg_nosec net/socket.c:724 [inline]
    sock_sendmsg net/socket.c:747 [inline]
    sock_write_iter+0x1aa/0x230 net/socket.c:1138
    call_write_iter include/linux/fs.h:1851 [inline]
    new_sync_write fs/read_write.c:491 [inline]
    vfs_write+0x463/0x760 fs/read_write.c:584
    ksys_write+0xeb/0x1a0 fs/read_write.c:637
    __do_sys_write fs/read_write.c:649 [inline]
    __se_sys_write fs/read_write.c:646 [inline]
    __x64_sys_write+0x42/0x50 fs/read_write.c:646
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1:
    netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022
    sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017
    ____sys_recvmsg+0x2db/0x310 net/socket.c:2718
    ___sys_recvmsg net/socket.c:2762 [inline]
    do_recvmmsg+0x2e5/0x710 net/socket.c:2856
    __sys_recvmmsg net/socket.c:2935 [inline]
    __do_sys_recvmmsg net/socket.c:2958 [inline]
    __se_sys_recvmmsg net/socket.c:2951 [inline]
    __x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x00 -> 0x01
    
    Fixes: 16b304f3404f ("netlink: Eliminate kmalloc in netlink dump operation.")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Wed May 10 00:29:56 2023 +0900

    nilfs2: fix use-after-free bug of nilfs_root in nilfs_evict_inode()
    
    commit 9b5a04ac3ad9898c4745cba46ea26de74ba56a8e upstream.
    
    During unmount process of nilfs2, nothing holds nilfs_root structure after
    nilfs2 detaches its writer in nilfs_detach_log_writer().  However, since
    nilfs_evict_inode() uses nilfs_root for some cleanup operations, it may
    cause use-after-free read if inodes are left in "garbage_list" and
    released by nilfs_dispose_list() at the end of nilfs_detach_log_writer().
    
    Fix this issue by modifying nilfs_evict_inode() to only clear inode
    without additional metadata changes that use nilfs_root if the file system
    is degraded to read-only or the writer is detached.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Closes: https://lkml.kernel.org/r/[email protected]
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
parisc: Allow to reboot machine after system halt [+ + +]
Author: Helge Deller <[email protected]>
Date:   Mon May 22 22:57:30 2023 +0200

    parisc: Allow to reboot machine after system halt
    
    commit 2028315cf59bb899a5ac7e87dc48ecb8fac7ac24 upstream.
    
    In case a machine can't power-off itself on system shutdown,
    allow the user to reboot it by pressing the RETURN key.
    
    Cc: <[email protected]> # v4.14+
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Fix flush_dcache_page() for usage from irq context [+ + +]
Author: Helge Deller <[email protected]>
Date:   Wed May 24 17:07:07 2023 +0200

    parisc: Fix flush_dcache_page() for usage from irq context
    
    commit 61e150fb310729c98227a5edf6e4a3619edc3702 upstream.
    
    Since at least kernel 6.1, flush_dcache_page() is called with IRQs
    disabled, e.g. from aio_complete().
    
    But the current implementation for flush_dcache_page() on parisc
    unintentionally re-enables IRQs, which may lead to deadlocks.
    
    Fix it by using xa_lock_irqsave() and xa_unlock_irqrestore()
    for the flush_dcache_mmap_*lock() macros instead.
    
    Cc: [email protected]
    Cc: [email protected] # 5.18+
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Handle kgdb breakpoints only in kernel context [+ + +]
Author: Helge Deller <[email protected]>
Date:   Wed May 24 14:34:58 2023 +0200

    parisc: Handle kgdb breakpoints only in kernel context
    
    commit 6888ff04e37d01295620a73f3f7efbc79f6ef152 upstream.
    
    The kernel kgdb break instructions should only be handled when running
    in kernel context.
    
    Cc: <[email protected]> # v5.4+
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
phy: st: miphy28lp: use _poll_timeout functions for waits [+ + +]
Author: Alain Volmat <[email protected]>
Date:   Fri Feb 10 23:43:08 2023 +0100

    phy: st: miphy28lp: use _poll_timeout functions for waits
    
    [ Upstream commit e3be4dd2c8d8aabfd2c3127d0e2e5754d3ae82d6 ]
    
    This commit introduces _poll_timeout functions usage instead of
    wait loops waiting for a status bit.
    
    Signed-off-by: Alain Volmat <[email protected]>
    Reviewed-by: Patrice Chotard <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
power: supply: bq27xxx: Fix bq27xxx_battery_update() race condition [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Sat Apr 15 20:23:32 2023 +0200

    power: supply: bq27xxx: Fix bq27xxx_battery_update() race condition
    
    commit 5c34c0aef185dcd10881847b9ebf20046aa77cb4 upstream.
    
    bq27xxx_battery_update() assumes / requires that it is only run once,
    not multiple times at the same time. But there are 3 possible callers:
    
    1. bq27xxx_battery_poll() delayed_work item handler
    2. bq27xxx_battery_irq_handler_thread() I2C IRQ handler
    3. bq27xxx_battery_setup()
    
    And there is no protection against these racing with each other,
    fix this race condition by making all callers take di->lock:
    
    - Rename bq27xxx_battery_update() to bq27xxx_battery_update_unlocked()
    
    - Add new bq27xxx_battery_update() which takes di->lock and then calls
      bq27xxx_battery_update_unlocked()
    
    - Make stale cache check code in bq27xxx_battery_get_property(), which
      already takes di->lock directly to check the jiffies, call
      bq27xxx_battery_update_unlocked() instead of messing with
      the delayed_work item
    
    - Make bq27xxx_battery_update_unlocked() mod the delayed-work item
      so that the next poll is delayed to poll_interval milliseconds after
      the last update independent of the source of the update
    
    Fixes: 740b755a3b34 ("bq27x00: Poll battery state")
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

power: supply: bq27xxx: Fix I2C IRQ race on remove [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Sat Apr 15 20:23:33 2023 +0200

    power: supply: bq27xxx: Fix I2C IRQ race on remove
    
    commit 444ff00734f3878cd54ddd1ed5e2e6dbea9326d5 upstream.
    
    devm_request_threaded_irq() requested IRQs are only free-ed after
    the driver's remove function has ran. So the IRQ could trigger and
    call bq27xxx_battery_update() after bq27xxx_battery_teardown() has
    already run.
    
    Switch to explicitly free-ing the IRQ in bq27xxx_battery_i2c_remove()
    to fix this.
    
    Fixes: 8807feb91b76 ("power: bq27xxx_battery: Add interrupt handling support")
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

power: supply: bq27xxx: Fix poll_interval handling and races on remove [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Sat Apr 15 20:23:34 2023 +0200

    power: supply: bq27xxx: Fix poll_interval handling and races on remove
    
    commit c00bc80462afc7963f449d7f21d896d2f629cacc upstream.
    
    Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0
    to avoid bq27xxx_battery_update() requeuing the delayed_work item.
    
    There are 2 problems with this:
    
    1. If the driver is unbound through sysfs, rather then the module being
       rmmod-ed, this changes poll_interval unexpectedly
    
    2. This is racy, after it being set poll_interval could be changed
       before bq27xxx_battery_update() checks it through
       /sys/module/bq27xxx_battery/parameters/poll_interval
    
    Fix this by added a removed attribute to struct bq27xxx_device_info and
    using that instead of setting poll_interval to 0.
    
    There also is another poll_interval related race on remove(), writing
    /sys/module/bq27xxx_battery/parameters/poll_interval will requeue
    the delayed_work item for all devices on the bq27xxx_battery_devices
    list and the device being removed was only removed from that list
    after cancelling the delayed_work item.
    
    Fix this by moving the removal from the bq27xxx_battery_devices list
    to before cancelling the delayed_work item.
    
    Fixes: 8cfaaa811894 ("bq27x00_battery: Fix OOPS caused by unregistring bq27x00 driver")
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

power: supply: leds: Fix blink to LED on transition [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Thu Apr 13 12:09:41 2023 +0200

    power: supply: leds: Fix blink to LED on transition
    
    commit e4484643991e0f6b89060092563f0dbab9450cbb upstream.
    
    When a battery's status changes from charging to full then
    the charging-blink-full-solid trigger tries to change
    the LED from blinking to solid/on.
    
    As is documented in include/linux/leds.h to deactivate blinking /
    to make the LED solid a LED_OFF must be send:
    
    """
             * Deactivate blinking again when the brightness is set to LED_OFF
             * via the brightness_set() callback.
    """
    
    led_set_brighness() calls with a brightness value other then 0 / LED_OFF
    merely change the brightness of the LED in its on state while it is
    blinking.
    
    So power_supply_update_bat_leds() must first send a LED_OFF event
    before the LED_FULL to disable blinking.
    
    Fixes: 6501f728c56f ("power_supply: Add new LED trigger charging-blink-solid-full")
    Signed-off-by: Hans de Goede <[email protected]>
    Reviewed-by: Vasily Khoruzhick <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

power: supply: sbs-charger: Fix INHIBITED bit for Status reg [+ + +]
Author: Daisuke Nojiri <[email protected]>
Date:   Mon Apr 24 11:25:58 2023 -0700

    power: supply: sbs-charger: Fix INHIBITED bit for Status reg
    
    commit b2f2a3c9800208b0db2c2e34b05323757117faa2 upstream.
    
    CHARGE_INHIBITED bit position of the ChargerStatus register is actually
    0 not 1. This patch corrects it.
    
    Fixes: feb583e37f8a8 ("power: supply: add sbs-charger driver")
    Signed-off-by: Daisuke Nojiri <[email protected]>
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
powerpc/64s/radix: Fix soft dirty tracking [+ + +]
Author: Michael Ellerman <[email protected]>
Date:   Thu May 11 21:42:24 2023 +1000

    powerpc/64s/radix: Fix soft dirty tracking
    
    commit 66b2ca086210732954a7790d63d35542936fc664 upstream.
    
    It was reported that soft dirty tracking doesn't work when using the
    Radix MMU.
    
    The tracking is supposed to work by clearing the soft dirty bit for a
    mapping and then write protecting the PTE. If/when the page is written
    to, a page fault occurs and the soft dirty bit is added back via
    pte_mkdirty(). For example in wp_page_reuse():
    
            entry = maybe_mkwrite(pte_mkdirty(entry), vma);
            if (ptep_set_access_flags(vma, vmf->address, vmf->pte, entry, 1))
                    update_mmu_cache(vma, vmf->address, vmf->pte);
    
    Unfortunately on radix _PAGE_SOFTDIRTY is being dropped by
    radix__ptep_set_access_flags(), called from ptep_set_access_flags(),
    meaning the soft dirty bit is not set even though the page has been
    written to.
    
    Fix it by adding _PAGE_SOFTDIRTY to the set of bits that are able to be
    changed in radix__ptep_set_access_flags().
    
    Fixes: b0b5e9b13047 ("powerpc/mm/radix: Add radix pte #defines")
    Cc: [email protected] # v4.7+
    Reported-by: Dan Horák <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
RDMA/core: Fix multiple -Warray-bounds warnings [+ + +]
Author: Gustavo A. R. Silva <[email protected]>
Date:   Tue Mar 21 17:47:03 2023 -0600

    RDMA/core: Fix multiple -Warray-bounds warnings
    
    [ Upstream commit aa4d540b4150052ae3b36d286b9c833a961ce291 ]
    
    GCC-13 (and Clang)[1] does not like to access a partially allocated
    object, since it cannot reason about it for bounds checking.
    
    In this case 140 bytes are allocated for an object of type struct
    ib_umad_packet:
    
            packet = kzalloc(sizeof(*packet) + IB_MGMT_RMPP_HDR, GFP_KERNEL);
    
    However, notice that sizeof(*packet) is only 104 bytes:
    
    struct ib_umad_packet {
            struct ib_mad_send_buf *   msg;                  /*     0     8 */
            struct ib_mad_recv_wc *    recv_wc;              /*     8     8 */
            struct list_head           list;                 /*    16    16 */
            int                        length;               /*    32     4 */
    
            /* XXX 4 bytes hole, try to pack */
    
            struct ib_user_mad         mad __attribute__((__aligned__(8))); /*    40    64 */
    
            /* size: 104, cachelines: 2, members: 5 */
            /* sum members: 100, holes: 1, sum holes: 4 */
            /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
            /* last cacheline: 40 bytes */
    } __attribute__((__aligned__(8)));
    
    and 36 bytes extra bytes are allocated for a flexible-array member in
    struct ib_user_mad:
    
    include/rdma/ib_mad.h:
    120 enum {
    ...
    123         IB_MGMT_RMPP_HDR = 36,
    ... }
    
    struct ib_user_mad {
            struct ib_user_mad_hdr     hdr;                  /*     0    64 */
            /* --- cacheline 1 boundary (64 bytes) --- */
            __u64                      data[] __attribute__((__aligned__(8))); /*    64     0 */
    
            /* size: 64, cachelines: 1, members: 2 */
            /* forced alignments: 1 */
    } __attribute__((__aligned__(8)));
    
    So we have sizeof(*packet) + IB_MGMT_RMPP_HDR == 140 bytes
    
    Then the address of the flex-array member (for which only 36 bytes were
    allocated) is casted and copied into a pointer to struct ib_rmpp_mad,
    which, in turn, is of size 256 bytes:
    
            rmpp_mad = (struct ib_rmpp_mad *) packet->mad.data;
    
    struct ib_rmpp_mad {
            struct ib_mad_hdr          mad_hdr;              /*     0    24 */
            struct ib_rmpp_hdr         rmpp_hdr;             /*    24    12 */
            u8                         data[220];            /*    36   220 */
    
            /* size: 256, cachelines: 4, members: 3 */
    };
    
    The thing is that those 36 bytes allocated for flex-array member data
    in struct ib_user_mad onlly account for the size of both struct ib_mad_hdr
    and struct ib_rmpp_hdr, but nothing is left for array u8 data[220].
    So, the compiler is legitimately complaining about accessing an object
    for which not enough memory was allocated.
    
    Apparently, the only members of struct ib_rmpp_mad that are relevant
    (that are actually being used) in function ib_umad_write() are mad_hdr
    and rmpp_hdr. So, instead of casting packet->mad.data to
    (struct ib_rmpp_mad *) create a new structure
    
    struct ib_rmpp_mad_hdr {
            struct ib_mad_hdr       mad_hdr;
            struct ib_rmpp_hdr      rmpp_hdr;
    } __packed;
    
    and cast packet->mad.data to (struct ib_rmpp_mad_hdr *).
    
    Notice that
    
            IB_MGMT_RMPP_HDR == sizeof(struct ib_rmpp_mad_hdr) == 36 bytes
    
    Refactor the rest of the code, accordingly.
    
    Fix the following warnings seen under GCC-13 and -Warray-bounds:
    drivers/infiniband/core/user_mad.c:564:50: warning: array subscript ‘struct ib_rmpp_mad[0]’ is partly outside array bounds of ‘unsigned char[140]’ [-Warray-bounds=]
    drivers/infiniband/core/user_mad.c:566:42: warning: array subscript ‘struct ib_rmpp_mad[0]’ is partly outside array bounds of ‘unsigned char[140]’ [-Warray-bounds=]
    drivers/infiniband/core/user_mad.c:618:25: warning: array subscript ‘struct ib_rmpp_mad[0]’ is partly outside array bounds of ‘unsigned char[140]’ [-Warray-bounds=]
    drivers/infiniband/core/user_mad.c:622:44: warning: array subscript ‘struct ib_rmpp_mad[0]’ is partly outside array bounds of ‘unsigned char[140]’ [-Warray-bounds=]
    
    Link: https://github.com/KSPP/linux/issues/273
    Link: https://godbolt.org/z/oYWaGM4Yb [1]
    Signed-off-by: Gustavo A. R. Silva <[email protected]>
    Link: https://lore.kernel.org/r/ZBpB91qQcB10m3Fw@work
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
recordmcount: Fix memory leaks in the uwrite function [+ + +]
Author: Hao Zeng <[email protected]>
Date:   Wed Apr 26 09:05:27 2023 +0800

    recordmcount: Fix memory leaks in the uwrite function
    
    [ Upstream commit fa359d068574d29e7d2f0fdd0ebe4c6a12b5cfb9 ]
    
    Common realloc mistake: 'file_append' nulled but not freed upon failure
    
    Link: https://lkml.kernel.org/r/[email protected]
    
    Signed-off-by: Hao Zeng <[email protected]>
    Suggested-by: Steven Rostedt <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regmap: cache: Return error in cache sync operations for REGCACHE_NONE [+ + +]
Author: Alexander Stein <[email protected]>
Date:   Mon Mar 13 08:18:11 2023 +0100

    regmap: cache: Return error in cache sync operations for REGCACHE_NONE
    
    [ Upstream commit fd883d79e4dcd2417c2b80756f22a2ff03b0f6e0 ]
    
    There is no sense in doing a cache sync on REGCACHE_NONE regmaps.
    Instead of panicking the kernel due to missing cache_ops, return an error
    to client driver.
    
    Signed-off-by: Alexander Stein <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/qdio: fix do_sqbs() inline assembly constraint [+ + +]
Author: Heiko Carstens <[email protected]>
Date:   Thu May 11 17:04:41 2023 +0200

    s390/qdio: fix do_sqbs() inline assembly constraint
    
    [ Upstream commit 2862a2fdfae875888e3c1c3634e3422e01d98147 ]
    
    Use "a" constraint instead of "d" constraint to pass the state parameter to
    the do_sqbs() inline assembly. This prevents that general purpose register
    zero is used for the state parameter.
    
    If the compiler would select general purpose register zero this would be
    problematic for the used instruction in rsy format: the register used for
    the state parameter is a base register. If the base register is general
    purpose register zero the contents of the register are unexpectedly ignored
    when the instruction is executed.
    
    This only applies to z/VM guests using QIOASSIST with dedicated (pass through)
    QDIO-based devices such as FCP [zfcp driver] as well as real OSA or
    HiperSockets [qeth driver].
    
    A possible symptom for this case using zfcp is the following repeating kernel
    message pattern:
    
    zfcp <devbusid>: A QDIO problem occurred
    zfcp <devbusid>: A QDIO problem occurred
    zfcp <devbusid>: qdio: ZFCP on SC <sc> using AI:1 QEBSM:1 PRI:1 TDD:1 SIGA: W
    zfcp <devbusid>: A QDIO problem occurred
    zfcp <devbusid>: A QDIO problem occurred
    
    Each of the qdio problem message can be accompanied by the following entries
    for the affected subchannel <sc> in
    /sys/kernel/debug/s390dbf/qdio_error/hex_ascii for zfcp or qeth:
    
    <sc> ccq: 69....
    <sc> SQBS ERROR.
    
    Reviewed-by: Benjamin Block <[email protected]>
    Cc: Steffen Maier <[email protected]>
    Fixes: 8129ee164267 ("[PATCH] s390: qdio V=V pass-through")
    Cc: <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

s390/qdio: get rid of register asm [+ + +]
Author: Heiko Carstens <[email protected]>
Date:   Tue Jun 22 15:26:16 2021 +0200

    s390/qdio: get rid of register asm
    
    [ Upstream commit d3e2ff5436d6ee38b572ba5c01dc7994769bec54 ]
    
    Reviewed-by: Benjamin Block <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Vasily Gorbik <[email protected]>
    Stable-dep-of: 2862a2fdfae8 ("s390/qdio: fix do_sqbs() inline assembly constraint")
    Signed-off-by: Sasha Levin <[email protected]>

 
samples/bpf: Fix fout leak in hbm's run_bpf_prog [+ + +]
Author: Hao Zeng <[email protected]>
Date:   Tue Apr 11 16:43:49 2023 +0800

    samples/bpf: Fix fout leak in hbm's run_bpf_prog
    
    [ Upstream commit 23acb14af1914010dd0aae1bbb7fab28bf518b8e ]
    
    Fix fout being fopen'ed but then not subsequently fclose'd. In the affected
    branch, fout is otherwise going out of scope.
    
    Signed-off-by: Hao Zeng <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
sched: Fix KCSAN noinstr violation [+ + +]
Author: Josh Poimboeuf <[email protected]>
Date:   Wed Apr 12 10:24:07 2023 -0700

    sched: Fix KCSAN noinstr violation
    
    [ Upstream commit e0b081d17a9f4e5c0cbb0e5fbeb1abe3de0f7e4e ]
    
    With KCSAN enabled, end_of_stack() can get out-of-lined.  Force it
    inline.
    
    Fixes the following warnings:
    
      vmlinux.o: warning: objtool: check_stackleak_irqoff+0x2b: call to end_of_stack() leaves .noinstr.text section
    
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lore.kernel.org/r/cc1b4d73d3a428a00d206242a68fdf99a934ca7b.1681320026.git.jpoimboe@kernel.org
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow [+ + +]
Author: Justin Tee <[email protected]>
Date:   Wed Mar 1 15:16:17 2023 -0800

    scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow
    
    [ Upstream commit c6087b82a9146826564a55c5ca0164cac40348f5 ]
    
    A static code analysis tool flagged the possibility of buffer overflow when
    using copy_from_user() for a debugfs entry.
    
    Currently, it is possible that copy_from_user() copies more bytes than what
    would fit in the mybuf char array.  Add a min() restriction check between
    sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect
    against buffer overflow.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Justin Tee <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Sat Mar 18 16:16:35 2023 +0800

    scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race condition
    
    [ Upstream commit f486893288f3e9b171b836f43853a6426515d800 ]
    
    mptlan_probe() calls mpt_register_lan_device() which initializes the
    &priv->post_buckets_task workqueue. A call to
    mpt_lan_wake_post_buckets_task() will subsequently start the work.
    
    During driver unload in mptlan_remove() the following race may occur:
    
    CPU0                  CPU1
    
                        |mpt_lan_post_receive_buckets_work()
    mptlan_remove()     |
      free_netdev()     |
        kfree(dev);     |
                        |
                        | dev->mtu
                        |   //use
    
    Fix this by finishing the work prior to cleaning up in mptlan_remove().
    
    [mkp: we really should remove mptlan instead of attempting to fix it]
    
    Signed-off-by: Zheng Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: target: iscsit: Free cmds before session free [+ + +]
Author: Dmitry Bogdanov <[email protected]>
Date:   Sat Mar 18 20:56:17 2023 -0500

    scsi: target: iscsit: Free cmds before session free
    
    [ Upstream commit d8990b5a4d065f38f35d69bcd627ec5a7f8330ca ]
    
    Commands from recovery entries are freed after session has been closed.
    That leads to use-after-free at command free or NPE with such call trace:
    
    Time2Retain timer expired for SID: 1, cleaning up iSCSI session.
    BUG: kernel NULL pointer dereference, address: 0000000000000140
    RIP: 0010:sbitmap_queue_clear+0x3a/0xa0
    Call Trace:
     target_release_cmd_kref+0xd1/0x1f0 [target_core_mod]
     transport_generic_free_cmd+0xd1/0x180 [target_core_mod]
     iscsit_free_cmd+0x53/0xd0 [iscsi_target_mod]
     iscsit_free_connection_recovery_entries+0x29d/0x320 [iscsi_target_mod]
     iscsit_close_session+0x13a/0x140 [iscsi_target_mod]
     iscsit_check_post_dataout+0x440/0x440 [iscsi_target_mod]
     call_timer_fn+0x24/0x140
    
    Move cleanup of recovery enrties to before session freeing.
    
    Reported-by: Forza <[email protected]>
    Signed-off-by: Dmitry Bogdanov <[email protected]>
    Signed-off-by: Mike Christie <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Maurizio Lombardi <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/memfd: Fix unknown type name build failure [+ + +]
Author: Hardik Garg <[email protected]>
Date:   Fri May 26 16:21:36 2023 -0700

    selftests/memfd: Fix unknown type name build failure
    
    Partially backport v6.3 commit 11f75a01448f ("selftests/memfd: add tests
    for MFD_NOEXEC_SEAL MFD_EXEC") to fix an unknown type name build error.
    In some systems, the __u64 typedef is not present due to differences in
    system headers, causing compilation errors like this one:
    
    fuse_test.c:64:8: error: unknown type name '__u64'
       64 | static __u64 mfd_assert_get_seals(int fd)
    
    This header includes the  __u64 typedef which increases the likelihood
    of successful compilation on a wider variety of systems.
    
    Signed-off-by: Hardik Garg <[email protected]>
    Reviewed-by: Tyler Hicks (Microsoft) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selftests: fib_tests: mute cleanup error message [+ + +]
Author: Po-Hsu Lin <[email protected]>
Date:   Thu May 18 12:37:59 2023 +0800

    selftests: fib_tests: mute cleanup error message
    
    commit d226b1df361988f885c298737d6019c863a25f26 upstream.
    
    In the end of the test, there will be an error message induced by the
    `ip netns del ns1` command in cleanup()
    
      Tests passed: 201
      Tests failed:   0
      Cannot remove namespace file "/run/netns/ns1": No such file or directory
    
    This can even be reproduced with just `./fib_tests.sh -h` as we're
    calling cleanup() on exit.
    
    Redirect the error message to /dev/null to mute it.
    
    V2: Update commit message and fixes tag.
    V3: resubmit due to missing netdev ML in V2
    
    Fixes: b60417a9f2b8 ("selftest: fib_tests: Always cleanup before exit")
    Signed-off-by: Po-Hsu Lin <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
serial: 8250: Reinit port->pm on port specific driver unbind [+ + +]
Author: Tony Lindgren <[email protected]>
Date:   Tue Apr 18 13:14:06 2023 +0300

    serial: 8250: Reinit port->pm on port specific driver unbind
    
    [ Upstream commit 04e82793f068d2f0ffe62fcea03d007a8cdc16a7 ]
    
    When we unbind a serial port hardware specific 8250 driver, the generic
    serial8250 driver takes over the port. After that we see an oops about 10
    seconds later. This can produce the following at least on some TI SoCs:
    
    Unhandled fault: imprecise external abort (0x1406)
    Internal error: : 1406 [#1] SMP ARM
    
    Turns out that we may still have the serial port hardware specific driver
    port->pm in use, and serial8250_pm() tries to call it after the port
    specific driver is gone:
    
    serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]
    uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]
    uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c
    __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c
    disassociate_ctty from do_exit+0x744/0xaac
    do_exit from do_group_exit+0x40/0x8c
    do_group_exit from __wake_up_parent+0x0/0x1c
    
    Let's fix the issue by calling serial8250_set_defaults() in
    serial8250_unregister_port(). This will set the port back to using
    the serial8250 default functions, and sets the port->pm to point to
    serial8250_pm.
    
    Signed-off-by: Tony Lindgren <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

serial: Add support for Advantech PCI-1611U card [+ + +]
Author: Vitaliy Tomin <[email protected]>
Date:   Sun Apr 23 11:45:12 2023 +0800

    serial: Add support for Advantech PCI-1611U card
    
    commit d2b00516de0e1d696724247098f6733a6ea53908 upstream.
    
    Add support for Advantech PCI-1611U card
    
    Advantech provides opensource drivers for this and many others card
    based on legacy copy of 8250_pci driver called adv950
    
    https://www.advantech.com/emt/support/details/driver?id=1-TDOIMJ
    
    It is hard to maintain to run as out of tree module on newer kernels.
    Just adding PCI ID to kernel 8250_pci works perfect.
    
    Signed-off-by: Vitaliy Tomin <[email protected]>
    Cc: stable <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: arc_uart: fix of_iomap leak in `arc_serial_probe` [+ + +]
Author: Ke Zhang <[email protected]>
Date:   Fri Apr 28 11:16:36 2023 +0800

    serial: arc_uart: fix of_iomap leak in `arc_serial_probe`
    
    [ Upstream commit 8ab5fc55d7f65d58a3c3aeadf11bdf60267cd2bd ]
    
    Smatch reports:
    
    drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn:
    'port->membase' from of_iomap() not released on lines: 631.
    
    In arc_serial_probe(), if uart_add_one_port() fails,
    port->membase is not released, which would cause a resource leak.
    
    To fix this, I replace of_iomap with devm_platform_ioremap_resource.
    
    Fixes: 8dbe1d5e09a7 ("serial/arc: inline the probe helper")
    Signed-off-by: Ke Zhang <[email protected]>
    Reviewed-by: Dongliang Mu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
spi: fsl-cpm: Use 16 bit mode for large transfers with even size [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Mon May 15 16:07:17 2023 +0200

    spi: fsl-cpm: Use 16 bit mode for large transfers with even size
    
    (cherry picked from upstream fc96ec826bced75cc6b9c07a4ac44bbf651337ab)
    
    On CPM, the RISC core is a lot more efficiant when doing transfers
    in 16-bits chunks than in 8-bits chunks, but unfortunately the
    words need to be byte swapped as seen in a previous commit.
    
    So, for large tranfers with an even size, allocate a temporary tx
    buffer and byte-swap data before and after transfer.
    
    This change allows setting higher speed for transfer. For instance
    on an MPC 8xx (CPM1 comms RISC processor), the documentation tells
    that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load
    at 25 MHz while a word transfer at the same speed uses 0.032%
    of CPM load. This means the speed can be 6 times higher in
    word mode for the same CPM load.
    
    For the time being, only do it on CPM1 as there must be a
    trade-off between the CPM load reduction and the CPU load required
    to byte swap the data.
    
    Signed-off-by: Christophe Leroy <[email protected]>
    Link: https://lore.kernel.org/r/f2e981f20f92dd28983c3949702a09248c23845c.1680371809.git.christophe.leroy@csgroup.eu
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

spi: fsl-spi: Re-organise transfer bits_per_word adaptation [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Mon May 15 16:07:16 2023 +0200

    spi: fsl-spi: Re-organise transfer bits_per_word adaptation
    
    (backported from upstream 8a5299a1278eadf1e08a598a5345c376206f171e)
    
    For different reasons, fsl-spi driver performs bits_per_word
    modifications for different reasons:
    - On CPU mode, to minimise amount of interrupts
    - On CPM/QE mode to work around controller byte order
    
    For CPU mode that's done in fsl_spi_prepare_message() while
    for CPM mode that's done in fsl_spi_setup_transfer().
    
    Reunify all of it in fsl_spi_prepare_message(), and catch
    impossible cases early through master's bits_per_word_mask
    instead of returning EINVAL later.
    
    Signed-off-by: Christophe Leroy <[email protected]>
    Link: https://lore.kernel.org/r/0ce96fe96e8b07cba0613e4097cfd94d09b8919a.1680371809.git.christophe.leroy@csgroup.eu
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

spi: spi-imx: fix MX51_ECSPI_* macros when cs > 3 [+ + +]
Author: Kevin Groeneveld <[email protected]>
Date:   Sat Mar 18 18:21:32 2023 -0400

    spi: spi-imx: fix MX51_ECSPI_* macros when cs > 3
    
    [ Upstream commit 87c614175bbf28d3fd076dc2d166bac759e41427 ]
    
    When using gpio based chip select the cs value can go outside the range
    0 – 3. The various MX51_ECSPI_* macros did not take this into consideration
    resulting in possible corruption of the configuration.
    
    For example for any cs value over 3 the SCLKPHA bits would not be set and
    other values in the register possibly corrupted.
    
    One way to fix this is to just mask the cs bits to 2 bits. This still
    allows all 4 native chip selects to work as well as gpio chip selects
    (which can use any of the 4 chip select configurations).
    
    Signed-off-by: Kevin Groeneveld <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
staging: rtl8192e: Replace macro RTL_PCI_DEVICE with PCI_DEVICE [+ + +]
Author: Philipp Hortmann <[email protected]>
Date:   Thu Feb 23 07:47:21 2023 +0100

    staging: rtl8192e: Replace macro RTL_PCI_DEVICE with PCI_DEVICE
    
    [ Upstream commit fda2093860df4812d69052a8cf4997e53853a340 ]
    
    Replace macro RTL_PCI_DEVICE with PCI_DEVICE to get rid of rtl819xp_ops
    which is empty.
    
    Signed-off-by: Philipp Hortmann <[email protected]>
    Link: https://lore.kernel.org/r/8b45ee783fa91196b7c9d6fc840a189496afd2f4.1677133271.git.philipp.g.hortmann@gmail.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
statfs: enforce statfs[64] structure initialization [+ + +]
Author: Ilya Leoshkevich <[email protected]>
Date:   Thu May 4 16:40:20 2023 +0200

    statfs: enforce statfs[64] structure initialization
    
    commit ed40866ec7d328b3dfb70db7e2011640a16202c3 upstream.
    
    s390's struct statfs and struct statfs64 contain padding, which
    field-by-field copying does not set. Initialize the respective structs
    with zeros before filling them and copying them to userspace, like it's
    already done for the compat versions of these structs.
    
    Found by KMSAN.
    
    [[email protected]: fixed typo in patch description]
    Acked-by: Heiko Carstens <[email protected]>
    Cc: [email protected] # v4.14+
    Signed-off-by: Ilya Leoshkevich <[email protected]>
    Reviewed-by: Andrew Morton <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tpm/tpm_tis: Disable interrupts for more Lenovo devices [+ + +]
Author: Jerry Snitselaar <[email protected]>
Date:   Wed May 10 17:54:03 2023 -0700

    tpm/tpm_tis: Disable interrupts for more Lenovo devices
    
    commit e7d3e5c4b1dd50a70b31524c3228c62bb41bbab2 upstream.
    
    The P360 Tiny suffers from an irq storm issue like the T490s, so add
    an entry for it to tpm_tis_dmi_table, and force polling. There also
    previously was a report from the previous attempt to enable interrupts
    that involved a ThinkPad L490. So an entry is added for it as well.
    
    Cc: [email protected]
    Reported-by: Peter Zijlstra <[email protected]> # P360 Tiny
    Closes: https://lore.kernel.org/linux-integrity/[email protected]/
    Signed-off-by: Jerry Snitselaar <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue May 23 09:33:05 2023 -0700

    udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().
    
    commit ad42a35bdfc6d3c0fc4cb4027d7b2757ce665665 upstream.
    
    syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while using
    IPPROTO_UDPLITE (0x88):
    
      14:25:52 executing program 1:
      r0 = socket$inet6(0xa, 0x80002, 0x88)
    
    We had a similar report [1] for probably sk_memory_allocated_add()
    in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fix
    NULL pointer dereference") fixed it by setting .memory_allocated for
    udplite_prot and udplitev6_prot.
    
    To fix the variant, we need to set either .sysctl_wmem_offset or
    .sysctl_rmem.
    
    Now UDP and UDPLITE share the same value for .memory_allocated, so we
    use the same .sysctl_wmem_offset for UDP and UDPLITE.
    
    [0]:
    general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023
    RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline]
    RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006
    Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8b
    RSP: 0018:ffffc90005d7f450 EFLAGS: 00010246
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000
    RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8
    RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000
    R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001
    FS:  0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40
    CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
    CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0
    Call Trace:
     <TASK>
     __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077
     udp_rmem_schedule net/ipv4/udp.c:1539 [inline]
     __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581
     __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline]
     udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775
     udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793
     __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline]
     __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013
     ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437
     ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482
     NF_HOOK include/linux/netfilter.h:303 [inline]
     NF_HOOK include/linux/netfilter.h:297 [inline]
     ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491
     ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585
     dst_input include/net/dst.h:468 [inline]
     ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]
     NF_HOOK include/linux/netfilter.h:303 [inline]
     NF_HOOK include/linux/netfilter.h:297 [inline]
     ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309
     __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491
     __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605
     netif_receive_skb_internal net/core/dev.c:5691 [inline]
     netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750
     tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553
     tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989
     tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035
     call_write_iter include/linux/fs.h:1868 [inline]
     new_sync_write fs/read_write.c:491 [inline]
     vfs_write+0x945/0xd50 fs/read_write.c:584
     ksys_write+0x12b/0x250 fs/read_write.c:637
     do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
     __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178
     do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203
     entry_SYSENTER_compat_after_hwframe+0x70/0x82
    RIP: 0023:0xf7f21579
    Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00
    RSP: 002b:00000000f7f1c590 EFLAGS: 00000282 ORIG_RAX: 0000000000000004
    RAX: ffffffffffffffda RBX: 00000000000000c8 RCX: 0000000020000040
    RDX: 0000000000000083 RSI: 00000000f734e000 RDI: 0000000000000000
    RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    Modules linked in:
    
    Link: https://lore.kernel.org/netdev/CANaxB-yCk8hhP68L4Q2nFOJht8sqgXGGQO2AftpHs0u1xyGG5A@mail.gmail.com/ [1]
    Fixes: 850cbaddb52d ("udp: use it's own memory accounting schema")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=444ca0907e96f7c5e48b
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb-storage: fix deadlock when a scsi command timeouts more than once [+ + +]
Author: Maxime Bizon <[email protected]>
Date:   Fri May 5 13:47:59 2023 +0200

    usb-storage: fix deadlock when a scsi command timeouts more than once
    
    commit a398d5eac6984316e71474e25b975688f282379b upstream.
    
    With faulty usb-storage devices, read/write can timeout, in that case
    the SCSI layer will abort and re-issue the command. USB storage has no
    internal timeout, it relies on SCSI layer aborting commands via
    .eh_abort_handler() for non those responsive devices.
    
    After two consecutive timeouts of the same command, SCSI layer calls
    .eh_device_reset_handler(), without calling .eh_abort_handler() first.
    
    With usb-storage, this causes a deadlock:
    
      -> .eh_device_reset_handler
        -> device_reset
          -> mutex_lock(&(us->dev_mutex));
    
    mutex already by usb_stor_control_thread(), which is waiting for
    command completion:
    
      -> usb_stor_control_thread (mutex taken here)
        -> usb_stor_invoke_transport
          -> usb_stor_Bulk_transport
            -> usb_stor_bulk_srb
              -> usb_stor_bulk_transfer_sglist
                -> usb_sg_wait
    
    Make sure we cancel any pending command in .eh_device_reset_handler()
    to avoid this.
    
    Signed-off-by: Maxime Bizon <[email protected]>
    Cc: [email protected]
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/all/ZEllnjMKT8ulZbJh@sakura/
    Reviewed-by: Alan Stern <[email protected]>
    Acked-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
USB: core: Add routines for endpoint checks in old drivers [+ + +]
Author: Alan Stern <[email protected]>
Date:   Mon Apr 10 15:37:07 2023 -0400

    USB: core: Add routines for endpoint checks in old drivers
    
    commit 13890626501ffda22b18213ddaf7930473da5792 upstream.
    
    Many of the older USB drivers in the Linux USB stack were written
    based simply on a vendor's device specification.  They use the
    endpoint information in the spec and assume these endpoints will
    always be present, with the properties listed, in any device matching
    the given vendor and product IDs.
    
    While that may have been true back then, with spoofing and fuzzing it
    is not true any more.  More and more we are finding that those old
    drivers need to perform at least a minimum of checking before they try
    to use any endpoint other than ep0.
    
    To make this checking as simple as possible, we now add a couple of
    utility routines to the USB core.  usb_check_bulk_endpoints() and
    usb_check_int_endpoints() take an interface pointer together with a
    list of endpoint addresses (numbers and directions).  They check that
    the interface's current alternate setting includes endpoints with
    those addresses and that each of these endpoints has the right type:
    bulk or interrupt, respectively.
    
    Although we already have usb_find_common_endpoints() and related
    routines meant for a similar purpose, they are not well suited for
    this kind of checking.  Those routines find endpoints of various
    kinds, but only one (either the first or the last) of each kind, and
    they don't verify that the endpoints' addresses agree with what the
    caller expects.
    
    In theory the new routines could be more general: They could take a
    particular altsetting as their argument instead of always using the
    interface's current altsetting.  In practice I think this won't matter
    too much; multiple altsettings tend to be used for transferring media
    (audio or visual) over isochronous endpoints, not bulk or interrupt.
    Drivers for such devices will generally require more sophisticated
    checking than these simplistic routines provide.
    
    Signed-off-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: dwc3: debugfs: Resume dwc3 before accessing registers [+ + +]
Author: Udipto Goswami <[email protected]>
Date:   Tue May 9 20:18:36 2023 +0530

    usb: dwc3: debugfs: Resume dwc3 before accessing registers
    
    commit 614ce6a2ea50068b45339257891e51e639ac9001 upstream.
    
    When the dwc3 device is runtime suspended, various required clocks are in
    disabled state and it is not guaranteed that access to any registers would
    work. Depending on the SoC glue, a register read could be as benign as
    returning 0 or be fatal enough to hang the system.
    
    In order to prevent such scenarios of fatal errors, make sure to resume
    dwc3 then allow the function to proceed.
    
    Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
    Cc: [email protected] #3.2: 30332eeefec8: debugfs: regset32: Add Runtime PM support
    Signed-off-by: Udipto Goswami <[email protected]>
    Reviewed-by: Johan Hovold <[email protected]>
    Tested-by: Johan Hovold <[email protected]>
    Acked-by: Thinh Nguyen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: gadget: u_ether: Convert prints to device prints [+ + +]
Author: Jon Hunter <[email protected]>
Date:   Thu Feb 9 12:53:18 2023 +0000

    usb: gadget: u_ether: Convert prints to device prints
    
    [ Upstream commit 938fc645317632d79c048608689683b5437496ea ]
    
    The USB ethernet gadget driver implements its own print macros which
    call printk. Device drivers should use the device prints that print the
    device name. Fortunately, the same macro names are defined in the header
    file 'linux/usb/composite.h' and these use the device prints. Therefore,
    remove the local definitions in the USB ethernet gadget driver and use
    those in 'linux/usb/composite.h'. The only difference is that now the
    device name is printed instead of the ethernet interface name.
    
    Tested using ethernet gadget on Jetson AGX Orin.
    
    Signed-off-by: Jon Hunter <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Link: https://lore.kernel.org/r/20230209[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 3c0f4f09c063 ("usb: gadget: u_ether: Fix host MAC address case")
    Signed-off-by: Sasha Levin <[email protected]>

usb: gadget: u_ether: Fix host MAC address case [+ + +]
Author: Konrad Gräfe <[email protected]>
Date:   Fri May 5 16:36:40 2023 +0200

    usb: gadget: u_ether: Fix host MAC address case
    
    [ Upstream commit 3c0f4f09c063e143822393d99cb2b19a85451c07 ]
    
    The CDC-ECM specification [1] requires to send the host MAC address as
    an uppercase hexadecimal string in chapter "5.4 Ethernet Networking
    Functional Descriptor":
        The Unicode character is chosen from the set of values 30h through
        39h and 41h through 46h (0-9 and A-F).
    
    However, snprintf(.., "%pm", ..) generates a lowercase MAC address
    string. While most host drivers are tolerant to this, UsbNcm.sys on
    Windows 10 is not. Instead it uses a different MAC address with all
    bytes set to zero including and after the first byte containing a
    lowercase letter. On Windows 11 Microsoft fixed it, but apparently they
    did not backport the fix.
    
    This change fixes the issue by upper-casing the MAC to comply with the
    specification.
    
    [1]: https://www.usb.org/document-library/class-definitions-communication-devices-12, file ECM120.pdf
    
    Fixes: bcd4a1c40bee ("usb: gadget: u_ether: construct with default values and add setters/getters")
    Cc: [email protected]
    Signed-off-by: Konrad Gräfe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
USB: sisusbvga: Add endpoint checks [+ + +]
Author: Alan Stern <[email protected]>
Date:   Mon Apr 10 15:38:22 2023 -0400

    USB: sisusbvga: Add endpoint checks
    
    commit df05a9b05e466a46725564528b277d0c570d0104 upstream.
    
    The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver:
    
    ------------[ cut here ]------------
    usb 1-1: BOGUS urb xfer, pipe 3 != type 1
    WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
    Modules linked in:
    CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
    Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7
    RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
    RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95
    RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000
    R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000003
    R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600
    FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline]
     sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379
     sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline]
     sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline]
     sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177
     sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869
    ...
    
    The problem was caused by the fact that the driver does not check
    whether the endpoints it uses are actually present and have the
    appropriate types.  This can be fixed by adding a simple check of
    the endpoints.
    
    Link: https://syzkaller.appspot.com/bug?extid=23be03b56c5259385d79
    Reported-and-tested-by: [email protected]
    Signed-off-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: typec: altmodes/displayport: fix pin_assignment_show [+ + +]
Author: Badhri Jagan Sridharan <[email protected]>
Date:   Mon May 8 21:44:43 2023 +0000

    usb: typec: altmodes/displayport: fix pin_assignment_show
    
    commit d8f28269dd4bf9b55c3fb376ae31512730a96fce upstream.
    
    This patch fixes negative indexing of buf array in pin_assignment_show
    when get_current_pin_assignments returns 0 i.e. no compatible pin
    assignments are found.
    
    BUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c
    ...
    Call trace:
    dump_backtrace+0x110/0x204
    dump_stack_lvl+0x84/0xbc
    print_report+0x358/0x974
    kasan_report+0x9c/0xfc
    __do_kernel_fault+0xd4/0x2d4
    do_bad_area+0x48/0x168
    do_tag_check_fault+0x24/0x38
    do_mem_abort+0x6c/0x14c
    el1_abort+0x44/0x68
    el1h_64_sync_handler+0x64/0xa4
    el1h_64_sync+0x78/0x7c
    pin_assignment_show+0x26c/0x33c
    dev_attr_show+0x50/0xc0
    
    Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
    Cc: [email protected]
    Signed-off-by: Badhri Jagan Sridharan <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: tcpm: fix multiple times discover svids error [+ + +]
Author: Frank Wang <[email protected]>
Date:   Thu Mar 16 16:11:49 2023 +0800

    usb: typec: tcpm: fix multiple times discover svids error
    
    [ Upstream commit dac3b192107b978198e89ec0f77375738352e0c8 ]
    
    PD3.0 Spec 6.4.4.3.2 say that only Responder supports 12 or more SVIDs,
    the Discover SVIDs Command Shall be executed multiple times until a
    Discover SVIDs VDO is returned ending either with a SVID value of
    0x0000 in the last part of the last VDO or with a VDO containing two
    SVIDs with values of 0x0000.
    
    In the current implementation, if the last VDO does not find that the
    Discover SVIDs Command would be executed multiple times even if the
    Responder SVIDs are less than 12, and we found some odd dockers just
    meet this case. So fix it.
    
    Acked-by: Heikki Krogerus <[email protected]>
    Signed-off-by: Frank Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
USB: UHCI: adjust zhaoxin UHCI controllers OverCurrent bit value [+ + +]
Author: Weitao Wang <[email protected]>
Date:   Sun Apr 23 18:59:52 2023 +0800

    USB: UHCI: adjust zhaoxin UHCI controllers OverCurrent bit value
    
    commit dddb342b5b9e482bb213aecc08cbdb201ea4f8da upstream.
    
    OverCurrent condition is not standardized in the UHCI spec.
    Zhaoxin UHCI controllers report OverCurrent bit active off.
    In order to handle OverCurrent condition correctly, the uhci-hcd
    driver needs to be told to expect the active-off behavior.
    
    Suggested-by: Alan Stern <[email protected]>
    Cc: [email protected]
    Signed-off-by: Weitao Wang <[email protected]>
    Acked-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

USB: usbtmc: Fix direction for 0-length ioctl control messages [+ + +]
Author: Alan Stern <[email protected]>
Date:   Mon May 1 14:22:35 2023 -0400

    USB: usbtmc: Fix direction for 0-length ioctl control messages
    
    commit 94d25e9128988c6a1fc9070f6e98215a95795bd8 upstream.
    
    The syzbot fuzzer found a problem in the usbtmc driver: When a user
    submits an ioctl for a 0-length control transfer, the driver does not
    check that the direction is set to OUT:
    
    ------------[ cut here ]------------
    usb 3-1: BOGUS control dir, pipe 80000b80 doesn't match bRequestType fd
    WARNING: CPU: 0 PID: 5100 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
    Modules linked in:
    CPU: 0 PID: 5100 Comm: syz-executor428 Not tainted 6.3.0-syzkaller-12049-g58390c8ce1bd #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
    RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
    Code: 7c 24 40 e8 1b 13 5c fb 48 8b 7c 24 40 e8 21 1d f0 fe 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 e0 b5 fc 8a e8 19 c8 23 fb <0f> 0b e9 9f ee ff ff e8 ed 12 5c fb 0f b6 1d 12 8a 3c 08 31 ff 41
    RSP: 0018:ffffc90003d2fb00 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff8880789e9058 RCX: 0000000000000000
    RDX: ffff888029593b80 RSI: ffffffff814c1447 RDI: 0000000000000001
    RBP: ffff88801ea742f8 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000001 R12: ffff88802915e528
    R13: 00000000000000fd R14: 0000000080000b80 R15: ffff8880222b3100
    FS:  0000555556ca63c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f9ef4d18150 CR3: 0000000073e5b000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
     usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
     usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153
     usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1954 [inline]
     usbtmc_ioctl+0x1b3d/0x2840 drivers/usb/class/usbtmc.c:2097
    
    To fix this, we must override the direction in the bRequestType field
    of the control request structure when the length is 0.
    
    Reported-and-tested-by: [email protected]
    Signed-off-by: Alan Stern <[email protected]>
    Link: https://lore.kernel.org/linux-usb/[email protected]/
    CC: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF [+ + +]
Author: George Kennedy <[email protected]>
Date:   Fri May 12 06:08:48 2023 -0500

    vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF
    
    [ Upstream commit 8fb9ea65c9d1338b0d2bb0a9122dc942cdd32357 ]
    
    After a call to console_unlock() in vcs_write() the vc_data struct can be
    freed by vc_port_destruct(). Because of that, the struct vc_data pointer
    must be reloaded in the while loop in vcs_write() after console_lock() to
    avoid a UAF when vcs_size() is called.
    
    Syzkaller reported a UAF in vcs_size().
    
    BUG: KASAN: slab-use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)
    Read of size 4 at addr ffff8880beab89a8 by task repro_vcs_size/4119
    
    Call Trace:
     <TASK>
    __asan_report_load4_noabort (mm/kasan/report_generic.c:380)
    vcs_size (drivers/tty/vt/vc_screen.c:215)
    vcs_write (drivers/tty/vt/vc_screen.c:664)
    vfs_write (fs/read_write.c:582 fs/read_write.c:564)
    ...
     <TASK>
    
    Allocated by task 1213:
    kmalloc_trace (mm/slab_common.c:1064)
    vc_allocate (./include/linux/slab.h:559 ./include/linux/slab.h:680
        drivers/tty/vt/vt.c:1078 drivers/tty/vt/vt.c:1058)
    con_install (drivers/tty/vt/vt.c:3334)
    tty_init_dev (drivers/tty/tty_io.c:1303 drivers/tty/tty_io.c:1415
        drivers/tty/tty_io.c:1392)
    tty_open (drivers/tty/tty_io.c:2082 drivers/tty/tty_io.c:2128)
    chrdev_open (fs/char_dev.c:415)
    do_dentry_open (fs/open.c:921)
    vfs_open (fs/open.c:1052)
    ...
    
    Freed by task 4116:
    kfree (mm/slab_common.c:1016)
    vc_port_destruct (drivers/tty/vt/vt.c:1044)
    tty_port_destructor (drivers/tty/tty_port.c:296)
    tty_port_put (drivers/tty/tty_port.c:312)
    vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))
    vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)
    tty_ioctl (drivers/tty/tty_io.c:2778)
    ...
    
    The buggy address belongs to the object at ffff8880beab8800
     which belongs to the cache kmalloc-1k of size 1024
    The buggy address is located 424 bytes inside of
     freed 1024-byte region [ffff8880beab8800, ffff8880beab8c00)
    
    The buggy address belongs to the physical page:
    page:00000000afc77580 refcount:1 mapcount:0 mapping:0000000000000000
        index:0x0 pfn:0xbeab8
    head:00000000afc77580 order:3 entire_mapcount:0 nr_pages_mapped:0
        pincount:0
    flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
    page_type: 0xffffffff()
    raw: 000fffffc0010200 ffff888100042dc0 ffffea000426de00 dead000000000002
    raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff8880beab8880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8880beab8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff8880beab8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                      ^
     ffff8880beab8a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8880beab8a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    Disabling lock debugging due to kernel taint
    
    Fixes: ac751efa6a0d ("console: rename acquire/release_console_sem() to console_lock/unlock()")
    Cc: stable <[email protected]>
    Reported-by: syzkaller <[email protected]>
    Signed-off-by: George Kennedy <[email protected]>
    Reviewed-by: Thomas Weißschuh <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

vc_screen: rewrite vcs_size to accept vc, not inode [+ + +]
Author: Jiri Slaby <[email protected]>
Date:   Tue Aug 18 10:56:55 2020 +0200

    vc_screen: rewrite vcs_size to accept vc, not inode
    
    [ Upstream commit 71d4abfab322e827a75304431fe0fad3c805cb80 ]
    
    It is weird to fetch the information from the inode over and over. Read
    and write already have the needed information, so rewrite vcs_size to
    accept a vc, attr and unicode and adapt vcs_lseek to that.
    
    Also make sure all sites check the return value of vcs_size for errors.
    
    And document it using kernel-doc.
    
    Signed-off-by: Jiri Slaby <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF")
    Signed-off-by: Sasha Levin <[email protected]>

 
vlan: fix a potential uninit-value in vlan_dev_hard_start_xmit() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue May 16 14:23:42 2023 +0000

    vlan: fix a potential uninit-value in vlan_dev_hard_start_xmit()
    
    [ Upstream commit dacab578c7c6cd06c50c89dfa36b0e0f10decd4e ]
    
    syzbot triggered the following splat [1], sending an empty message
    through pppoe_sendmsg().
    
    When VLAN_FLAG_REORDER_HDR flag is set, vlan_dev_hard_header()
    does not push extra bytes for the VLAN header, because vlan is offloaded.
    
    Unfortunately vlan_dev_hard_start_xmit() first reads veth->h_vlan_proto
    before testing (vlan->flags & VLAN_FLAG_REORDER_HDR).
    
    We need to swap the two conditions.
    
    [1]
    BUG: KMSAN: uninit-value in vlan_dev_hard_start_xmit+0x171/0x7f0 net/8021q/vlan_dev.c:111
    vlan_dev_hard_start_xmit+0x171/0x7f0 net/8021q/vlan_dev.c:111
    __netdev_start_xmit include/linux/netdevice.h:4883 [inline]
    netdev_start_xmit include/linux/netdevice.h:4897 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x253/0xa20 net/core/dev.c:3596
    __dev_queue_xmit+0x3c7f/0x5ac0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3053 [inline]
    pppoe_sendmsg+0xa93/0xb80 drivers/net/ppp/pppoe.c:900
    sock_sendmsg_nosec net/socket.c:724 [inline]
    sock_sendmsg net/socket.c:747 [inline]
    ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501
    ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555
    __sys_sendmmsg+0x411/0xa50 net/socket.c:2641
    __do_sys_sendmmsg net/socket.c:2670 [inline]
    __se_sys_sendmmsg net/socket.c:2667 [inline]
    __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2667
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Uninit was created at:
    slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:774
    slab_alloc_node mm/slub.c:3452 [inline]
    kmem_cache_alloc_node+0x543/0xab0 mm/slub.c:3497
    kmalloc_reserve+0x148/0x470 net/core/skbuff.c:520
    __alloc_skb+0x3a7/0x850 net/core/skbuff.c:606
    alloc_skb include/linux/skbuff.h:1277 [inline]
    sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2583
    pppoe_sendmsg+0x3af/0xb80 drivers/net/ppp/pppoe.c:867
    sock_sendmsg_nosec net/socket.c:724 [inline]
    sock_sendmsg net/socket.c:747 [inline]
    ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501
    ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555
    __sys_sendmmsg+0x411/0xa50 net/socket.c:2641
    __do_sys_sendmmsg net/socket.c:2670 [inline]
    __se_sys_sendmmsg net/socket.c:2667 [inline]
    __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2667
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    CPU: 0 PID: 29770 Comm: syz-executor.0 Not tainted 6.3.0-rc6-syzkaller-gc478e5b17829 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vsock: avoid to close connected socket after the timeout [+ + +]
Author: Zhuang Shengen <[email protected]>
Date:   Thu May 11 19:34:30 2023 +0800

    vsock: avoid to close connected socket after the timeout
    
    [ Upstream commit 6d4486efe9c69626cab423456169e250a5cd3af5 ]
    
    When client and server establish a connection through vsock,
    the client send a request to the server to initiate the connection,
    then start a timer to wait for the server's response. When the server's
    RESPONSE message arrives, the timer also times out and exits. The
    server's RESPONSE message is processed first, and the connection is
    established. However, the client's timer also times out, the original
    processing logic of the client is to directly set the state of this vsock
    to CLOSE and return ETIMEDOUT. It will not notify the server when the port
    is released, causing the server port remain.
    when client's vsock_connect timeout,it should check sk state is
    ESTABLISHED or not. if sk state is ESTABLISHED, it means the connection
    is established, the client should not set the sk state to CLOSE
    
    Note: I encountered this issue on kernel-4.18, which can be fixed by
    this patch. Then I checked the latest code in the community
    and found similar issue.
    
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Signed-off-by: Zhuang Shengen <[email protected]>
    Reviewed-by: Stefano Garzarella <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
watchdog: sp5100_tco: Immediately trigger upon starting. [+ + +]
Author: Gregory Oakes <[email protected]>
Date:   Thu Mar 16 15:13:12 2023 -0500

    watchdog: sp5100_tco: Immediately trigger upon starting.
    
    commit 4eda19cc8a29cde3580ed73bf11dc73b4e757697 upstream.
    
    The watchdog countdown is supposed to begin when the device file is
    opened. Instead, it would begin countdown upon the first write to or
    close of the device file. Now, the ping operation is called within the
    start operation which ensures the countdown begins. From experimenation,
    it does not appear possible to do this with a single write including
    both the start bit and the trigger bit. So, it is done as two distinct
    writes.
    
    Signed-off-by: Gregory Oakes <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Cc: Mario Limonciello <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex [+ + +]
Author: Hector Martin <[email protected]>
Date:   Tue Feb 14 18:24:19 2023 +0900

    wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex
    
    [ Upstream commit 89b89e52153fda2733562776c7c9d9d3ebf8dd6d ]
    
    Apparently the hex passphrase mechanism does not work on newer
    chips/firmware (e.g. BCM4387). It seems there was a simple way of
    passing it in binary all along, so use that and avoid the hexification.
    
    OpenBSD has been doing it like this from the beginning, so this should
    work on all chips.
    
    Also clear the structure before setting the PMK. This was leaking
    uninitialized stack contents to the device.
    
    Reviewed-by: Linus Walleij <[email protected]>
    Reviewed-by: Arend van Spriel <[email protected]>
    Signed-off-by: Hector Martin <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/20[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtrace [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Tue Apr 18 15:25:46 2023 +0200

    wifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtrace
    
    [ Upstream commit ef16799640865f937719f0771c93be5dca18adc6 ]
    
    A received TKIP key may be up to 32 bytes because it may contain
    MIC rx/tx keys too. These are not used by iwl and copying these
    over overflows the iwl_keyinfo.key field.
    
    Add a check to not copy more data to iwl_keyinfo.key then will fit.
    
    This fixes backtraces like this one:
    
     memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16)
     WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm]
     <snip>
     Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017
     RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm]
     <snip>
     Call Trace:
      <TASK>
      iwl_set_dynamic_key+0x1f0/0x220 [iwldvm]
      iwlagn_mac_set_key+0x1e4/0x280 [iwldvm]
      drv_set_key+0xa4/0x1b0 [mac80211]
      ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211]
      ieee80211_key_replace+0x22d/0x8e0 [mac80211]
     <snip>
    
    Link: https://www.alionet.org/index.php?topic=1469.0
    Link: https://lore.kernel.org/linux-wireless/[email protected]/
    Link: https://lore.kernel.org/linux-wireless/[email protected]/
    Cc: Kees Cook <[email protected]>
    Suggested-by: Johannes Berg <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: mvm: don't trust firmware n_channels [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Sun May 14 12:15:53 2023 +0300

    wifi: iwlwifi: mvm: don't trust firmware n_channels
    
    [ Upstream commit 682b6dc29d98e857e6ca4bbc077c7dc2899b7473 ]
    
    If the firmware sends us a corrupted MCC response with
    n_channels much larger than the command response can be,
    we might copy far too much (uninitialized) memory and
    even crash if the n_channels is large enough to make it
    run out of the one page allocated for the FW response.
    
    Fix that by checking the lengths. Doing a < comparison
    would be sufficient, but the firmware should be doing
    it correctly, so check more strictly.
    
    Fixes: dcaf9f5ecb6f ("iwlwifi: mvm: add MCC update FW API")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Gregory Greenman <[email protected]>
    Link: https://lore.kernel.org/r/20230514120631.d7b233139eb4.I51fd319df8e9d41881fc8450e83d78049518a79a@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf [+ + +]
Author: Hyunwoo Kim <[email protected]>
Date:   Fri Apr 14 13:11:59 2023 +0300

    wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf
    
    [ Upstream commit 58d1b717879bfeabe09b35e41ad667c79933eb2e ]
    
    An integer overflow occurs in the iwl_write_to_user_buf() function,
    which is called by the iwl_dbgfs_monitor_data_read() function.
    
    static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count,
                                      void *buf, ssize_t *size,
                                      ssize_t *bytes_copied)
    {
            int buf_size_left = count - *bytes_copied;
    
            buf_size_left = buf_size_left - (buf_size_left % sizeof(u32));
            if (*size > buf_size_left)
                    *size = buf_size_left;
    
    If the user passes a SIZE_MAX value to the "ssize_t count" parameter,
    the ssize_t count parameter is assigned to "int buf_size_left".
    Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a
    negative number, so "*size" is assigned "buf_size_left" and goes into
    the third argument of the copy_to_user function, causing a heap overflow.
    
    This is not a security vulnerability because iwl_dbgfs_monitor_data_read()
    is a debugfs operation with 0400 privileges.
    
    Signed-off-by: Hyunwoo Kim <[email protected]>
    Signed-off-by: Gregory Greenman <[email protected]>
    Link: https://lore.kernel.org/r/20230414130637.2d80ace81532.Iecfba549e0e0be21bbb0324675392e42e75bd5ad@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: pcie: fix possible NULL pointer dereference [+ + +]
Author: Daniel Gabay <[email protected]>
Date:   Thu Apr 13 21:40:32 2023 +0300

    wifi: iwlwifi: pcie: fix possible NULL pointer dereference
    
    [ Upstream commit b655b9a9f8467684cfa8906713d33b71ea8c8f54 ]
    
    It is possible that iwl_pci_probe() will fail and free the trans,
    then afterwards iwl_pci_remove() will be called and crash by trying
    to access trans which is already freed, fix it.
    
    iwlwifi 0000:01:00.0: Detected crf-id 0xa5a5a5a2, cnv-id 0xa5a5a5a2
                          wfpm id 0xa5a5a5a2
    iwlwifi 0000:01:00.0: Can't find a correct rfid for crf id 0x5a2
    ...
    BUG: kernel NULL pointer dereference, address: 0000000000000028
    ...
    RIP: 0010:iwl_pci_remove+0x12/0x30 [iwlwifi]
    pci_device_remove+0x3e/0xb0
    device_release_driver_internal+0x103/0x1f0
    driver_detach+0x4c/0x90
    bus_remove_driver+0x5c/0xd0
    driver_unregister+0x31/0x50
    pci_unregister_driver+0x40/0x90
    iwl_pci_unregister_driver+0x15/0x20 [iwlwifi]
    __exit_compat+0x9/0x98 [iwlwifi]
    __x64_sys_delete_module+0x147/0x260
    
    Signed-off-by: Daniel Gabay <[email protected]>
    Signed-off-by: Gregory Greenman <[email protected]>
    Link: https://lore.kernel.org/r/20230413213309.082f6e21341b.I0db21d7fa9a828d571ca886713bd0b5d0b6e1e5c@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/mm: Avoid incomplete Global INVLPG flushes [+ + +]
Author: Dave Hansen <[email protected]>
Date:   Tue May 16 12:24:25 2023 -0700

    x86/mm: Avoid incomplete Global INVLPG flushes
    
    commit ce0b15d11ad837fbacc5356941712218e38a0a83 upstream.
    
    The INVLPG instruction is used to invalidate TLB entries for a
    specified virtual address.  When PCIDs are enabled, INVLPG is supposed
    to invalidate TLB entries for the specified address for both the
    current PCID *and* Global entries.  (Note: Only kernel mappings set
    Global=1.)
    
    Unfortunately, some INVLPG implementations can leave Global
    translations unflushed when PCIDs are enabled.
    
    As a workaround, never enable PCIDs on affected processors.
    
    I expect there to eventually be microcode mitigations to replace this
    software workaround.  However, the exact version numbers where that
    will happen are not known today.  Once the version numbers are set in
    stone, the processor list can be tweaked to only disable PCIDs on
    affected processors with affected microcode.
    
    Note: if anyone wants a quick fix that doesn't require patching, just
    stick 'nopcid' on your kernel command-line.
    
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Signed-off-by: Daniel Sneddon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/show_trace_log_lvl: Ensure stack pointer is aligned, again [+ + +]
Author: Vernon Lovejoy <[email protected]>
Date:   Fri May 12 12:42:32 2023 +0200

    x86/show_trace_log_lvl: Ensure stack pointer is aligned, again
    
    commit 2e4be0d011f21593c6b316806779ba1eba2cd7e0 upstream.
    
    The commit e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned")
    tried to align the stack pointer in show_trace_log_lvl(), otherwise the
    "stack < stack_info.end" check can't guarantee that the last read does
    not go past the end of the stack.
    
    However, we have the same problem with the initial value of the stack
    pointer, it can also be unaligned. So without this patch this trivial
    kernel module
    
            #include <linux/module.h>
    
            static int init(void)
            {
                    asm volatile("sub    $0x4,%rsp");
                    dump_stack();
                    asm volatile("add    $0x4,%rsp");
    
                    return -EAGAIN;
            }
    
            module_init(init);
            MODULE_LICENSE("GPL");
    
    crashes the kernel.
    
    Fixes: e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned")
    Signed-off-by: Vernon Lovejoy <[email protected]>
    Signed-off-by: Oleg Nesterov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/topology: Fix erroneous smp_num_siblings on Intel Hybrid platforms [+ + +]
Author: Zhang Rui <[email protected]>
Date:   Thu Mar 23 09:56:40 2023 +0800

    x86/topology: Fix erroneous smp_num_siblings on Intel Hybrid platforms
    
    commit edc0a2b5957652f4685ef3516f519f84807087db upstream.
    
    Traditionally, all CPUs in a system have identical numbers of SMT
    siblings.  That changes with hybrid processors where some logical CPUs
    have a sibling and others have none.
    
    Today, the CPU boot code sets the global variable smp_num_siblings when
    every CPU thread is brought up. The last thread to boot will overwrite
    it with the number of siblings of *that* thread. That last thread to
    boot will "win". If the thread is a Pcore, smp_num_siblings == 2.  If it
    is an Ecore, smp_num_siblings == 1.
    
    smp_num_siblings describes if the *system* supports SMT.  It should
    specify the maximum number of SMT threads among all cores.
    
    Ensure that smp_num_siblings represents the system-wide maximum number
    of siblings by always increasing its value. Never allow it to decrease.
    
    On MeteorLake-P platform, this fixes a problem that the Ecore CPUs are
    not updated in any cpu sibling map because the system is treated as an
    UP system when probing Ecore CPUs.
    
    Below shows part of the CPU topology information before and after the
    fix, for both Pcore and Ecore CPU (cpu0 is Pcore, cpu 12 is Ecore).
    ...
    -/sys/devices/system/cpu/cpu0/topology/package_cpus:000fff
    -/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-11
    +/sys/devices/system/cpu/cpu0/topology/package_cpus:3fffff
    +/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-21
    ...
    -/sys/devices/system/cpu/cpu12/topology/package_cpus:001000
    -/sys/devices/system/cpu/cpu12/topology/package_cpus_list:12
    +/sys/devices/system/cpu/cpu12/topology/package_cpus:3fffff
    +/sys/devices/system/cpu/cpu12/topology/package_cpus_list:0-21
    
    Notice that the "before" 'package_cpus_list' has only one CPU.  This
    means that userspace tools like lscpu will see a little laptop like
    an 11-socket system:
    
    -Core(s) per socket:  1
    -Socket(s):           11
    +Core(s) per socket:  16
    +Socket(s):           1
    
    This is also expected to make the scheduler do rather wonky things
    too.
    
    [ dhansen: remove CPUID detail from changelog, add end user effects ]
    
    CC: [email protected]
    Fixes: bbb65d2d365e ("x86: use cpuid vector 0xb when available for detecting cpu topology")
    Fixes: 95f3d39ccf7a ("x86/cpu/topology: Provide detect_extended_topology_early()")
    Suggested-by: Len Brown <[email protected]>
    Signed-off-by: Zhang Rui <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Acked-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lore.kernel.org/all/20230323015640.27906-1-rui.zhang%40intel.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
xen/pvcalls-back: fix double frees with pvcalls_new_active_socket() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed May 3 18:11:35 2023 +0300

    xen/pvcalls-back: fix double frees with pvcalls_new_active_socket()
    
    commit 8fafac202d18230bb9926bda48e563fd2cce2a4f upstream.
    
    In the pvcalls_new_active_socket() function, most error paths call
    pvcalls_back_release_active(fedata->dev, fedata, map) which calls
    sock_release() on "sock".  The bug is that the caller also frees sock.
    
    Fix this by making every error path in pvcalls_new_active_socket()
    release the sock, and don't free it in the caller.
    
    Fixes: 5db4d286a8ef ("xen/pvcalls: implement connect command")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Juergen Gross <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>