Changelog in Linux kernel 5.10.223

 
ACPI: EC: Abort address space access upon error [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Wed May 22 23:36:48 2024 +0200

    ACPI: EC: Abort address space access upon error
    
    [ Upstream commit f6f172dc6a6d7775b2df6adfd1350700e9a847ec ]
    
    When a multi-byte address space access is requested, acpi_ec_read()/
    acpi_ec_write() is being called multiple times.
    
    Abort such operations if a single call to acpi_ec_read() /
    acpi_ec_write() fails, as the data read from / written to the EC
    might be incomplete.
    
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: EC: Avoid returning AE_OK on errors in address space handler [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Wed May 22 23:36:49 2024 +0200

    ACPI: EC: Avoid returning AE_OK on errors in address space handler
    
    [ Upstream commit c4bd7f1d78340e63de4d073fd3dbe5391e2996e5 ]
    
    If an error code other than EINVAL, ENODEV or ETIME is returned
    by acpi_ec_read() / acpi_ec_write(), then AE_OK is incorrectly
    returned by acpi_ec_space_handler().
    
    Fix this by only returning AE_OK on success, and return AE_ERROR
    otherwise.
    
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: processor_idle: Fix invalid comparison with insertion sort for latency [+ + +]
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date:   Tue Jul 2 04:56:39 2024 +0800

    ACPI: processor_idle: Fix invalid comparison with insertion sort for latency
    
    commit 233323f9b9f828cd7cd5145ad811c1990b692542 upstream.
    
    The acpi_cst_latency_cmp() comparison function currently used for
    sorting C-state latencies does not satisfy transitivity, causing
    incorrect sorting results.
    
    Specifically, if there are two valid acpi_processor_cx elements A and B
    and one invalid element C, it may occur that A < B, A = C, and B = C.
    Sorting algorithms assume that if A < B and A = C, then C < B, leading
    to incorrect ordering.
    
    Given the small size of the array (<=8), we replace the library sort
    function with a simple insertion sort that properly ignores invalid
    elements and sorts valid ones based on latency. This change ensures
    correct ordering of the C-state latencies.
    
    Fixes: 65ea8f2c6e23 ("ACPI: processor idle: Fix up C-state latency if not ordered")
    Reported-by: Julian Sikorski <belegdol@gmail.com>
    Closes: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com
    Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
    Tested-by: Julian Sikorski <belegdol@gmail.com>
    Cc: All applicable <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240701205639.117194-1-visitorckw@gmail.com
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ALSA: dmaengine: Synchronize dma channel after drop() [+ + +]
Author: Jai Luthra <j-luthra@ti.com>
Date:   Tue Jun 11 18:02:55 2024 +0530

    ALSA: dmaengine: Synchronize dma channel after drop()
    
    [ Upstream commit e8343410ddf08fc36a9b9cc7c51a4e53a262d4c6 ]
    
    Sometimes the stream may be stopped due to XRUN events, in which case
    the userspace can call snd_pcm_drop() and snd_pcm_prepare() to stop and
    start the stream again.
    
    In these cases, we must wait for the DMA channel to synchronize before
    marking the stream as prepared for playback, as the DMA channel gets
    stopped by drop() without any synchronization. Make sure the ALSA core
    synchronizes the DMA channel by adding a sync_stop() hook.
    
    Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Signed-off-by: Jai Luthra <j-luthra@ti.com>
    Link: https://lore.kernel.org/r/20240611-asoc_next-v3-1-fcfd84b12164@ti.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: dmaengine_pcm: terminate dmaengine before synchronize [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Thu Jun 20 10:40:18 2024 +0800

    ALSA: dmaengine_pcm: terminate dmaengine before synchronize
    
    [ Upstream commit 6a7db25aad8ce6512b366d2ce1d0e60bac00a09d ]
    
    When dmaengine supports pause function, in suspend state,
    dmaengine_pause() is called instead of dmaengine_terminate_async(),
    
    In end of playback stream, the runtime->state will go to
    SNDRV_PCM_STATE_DRAINING, if system suspend & resume happen
    at this time, application will not resume playback stream, the
    stream will be closed directly, the dmaengine_terminate_async()
    will not be called before the dmaengine_synchronize(), which
    violates the call sequence for dmaengine_synchronize().
    
    This behavior also happens for capture streams, but there is no
    SNDRV_PCM_STATE_DRAINING state for capture. So use
    dmaengine_tx_status() to check the DMA status if the status is
    DMA_PAUSED, then call dmaengine_terminate_async() to terminate
    dmaengine before dmaengine_synchronize().
    
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://patch.msgid.link/1718851218-27803-1-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: Add more codec ID to no shutup pins list [+ + +]
Author: Kailang Yang <kailang@realtek.com>
Date:   Tue Jun 18 14:16:04 2024 +0800

    ALSA: hda/realtek: Add more codec ID to no shutup pins list
    
    [ Upstream commit 70794b9563fe011988bcf6a081af9777e63e8d37 ]
    
    If it enter to runtime D3 state, it didn't shutup Headset MIC pin.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Link: https://lore.kernel.org/r/8d86f61e7d6f4a03b311e4eb4e5caaef@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: Enable headset mic on Positivo SU C1400 [+ + +]
Author: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Date:   Fri Jul 12 15:06:42 2024 -0300

    ALSA: hda/realtek: Enable headset mic on Positivo SU C1400
    
    commit 8fc1e8b230771442133d5cf5fa4313277aa2bb8b upstream.
    
    Positivo SU C1400 is equipped with ALC256, and it needs
    ALC269_FIXUP_ASPIRE_HEADSET_MIC quirk to make its headset mic work.
    
    Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240712180642.22564-1-edson.drosdeck@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Fix the speaker output on Samsung Galaxy Book Pro 360 [+ + +]
Author: Seunghun Han <kkamagui@gmail.com>
Date:   Thu Jul 18 17:09:08 2024 +0900

    ALSA: hda/realtek: Fix the speaker output on Samsung Galaxy Book Pro 360
    
    commit d7063c08738573fc2f3296da6d31a22fa8aa843a upstream.
    
    Samsung Galaxy Book Pro 360 (13" 2022 NT935QDB-KC71S) with codec SSID
    144d:c1a4 requires the same workaround to enable the speaker amp
    as other Samsung models with the ALC298 codec.
    
    Signed-off-by: Seunghun Han <kkamagui@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240718080908.8677-1-kkamagui@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/relatek: Enable Mute LED on HP Laptop 15-gw0xxx [+ + +]
Author: Aivaz Latypov <reichaivaz@gmail.com>
Date:   Tue Jun 25 13:12:02 2024 +0500

    ALSA: hda/relatek: Enable Mute LED on HP Laptop 15-gw0xxx
    
    [ Upstream commit 1d091a98c399c17d0571fa1d91a7123a698446e4 ]
    
    This HP Laptop uses ALC236 codec with COEF 0x07 controlling
    the mute LED. Enable existing quirk for this device.
    
    Signed-off-by: Aivaz Latypov <reichaivaz@gmail.com>
    Link: https://patch.msgid.link/20240625081217.1049-1-reichaivaz@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: pcm_dmaengine: Don't synchronize DMA channel when DMA is paused [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Wed Jul 17 14:44:53 2024 +0800

    ALSA: pcm_dmaengine: Don't synchronize DMA channel when DMA is paused
    
    commit 88e98af9f4b5b0d60c1fe7f7f2701b5467691e75 upstream.
    
    When suspended, the DMA channel may enter PAUSE state if dmaengine_pause()
    is supported by DMA.
    At this state, dmaengine_synchronize() should not be called, otherwise
    the DMA channel can't be resumed successfully.
    
    Fixes: e8343410ddf0 ("ALSA: dmaengine: Synchronize dma channel after drop()")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/1721198693-27636-1-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: armv8_deprecated: Fix warning in isndep cpuhp starting process [+ + +]
Author: Wei Li <liwei391@huawei.com>
Date:   Tue Apr 23 17:35:01 2024 +0800

    arm64: armv8_deprecated: Fix warning in isndep cpuhp starting process
    
    [ Upstream commit 14951beaec93696b092a906baa0f29322cf34004 ]
    
    The function run_all_insn_set_hw_mode() is registered as startup callback
    of 'CPUHP_AP_ARM64_ISNDEP_STARTING', it invokes set_hw_mode() methods of
    all emulated instructions.
    
    As the STARTING callbacks are not expected to fail, if one of the
    set_hw_mode() fails, e.g. due to el0 mixed-endian is not supported for
    'setend', it will report a warning:
    
    ```
    CPU[2] cannot support the emulation of setend
    CPU 2 UP state arm64/isndep:starting (136) failed (-22)
    CPU2: Booted secondary processor 0x0000000002 [0x414fd0c1]
    ```
    
    To fix it, add a check for INSN_UNAVAILABLE status and skip the process.
    
    Signed-off-by: Wei Li <liwei391@huawei.com>
    Tested-by: Huisong Li <lihuisong@huawei.com>
    Link: https://lore.kernel.org/r/20240423093501.3460764-1-liwei391@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8996: Disable SS instance in Parkmode for USB [+ + +]
Author: Krishna Kurapati <quic_kriskura@quicinc.com>
Date:   Thu Jul 4 20:58:47 2024 +0530

    arm64: dts: qcom: msm8996: Disable SS instance in Parkmode for USB
    
    commit 44ea1ae3cf95db97e10d6ce17527948121f1dd4b upstream.
    
    For Gen-1 targets like MSM8996, it is seen that stressing out the
    controller in host mode results in HC died error:
    
     xhci-hcd.12.auto: xHCI host not responding to stop endpoint command
     xhci-hcd.12.auto: xHCI host controller not responding, assume dead
     xhci-hcd.12.auto: HC died; cleaning up
    
    And at this instant only restarting the host mode fixes it. Disable
    SuperSpeed instance in park mode for MSM8996 to mitigate this issue.
    
    Cc: stable@vger.kernel.org
    Fixes: 1e39255ed29d ("arm64: dts: msm8996: Add device node for qcom,dwc3")
    Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20240704152848.3380602-8-quic_kriskura@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ARM: 9324/1: fix get_user() broken with veneer [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Sep 26 17:09:03 2023 +0100

    ARM: 9324/1: fix get_user() broken with veneer
    
    commit 24d3ba0a7b44c1617c27f5045eecc4f34752ab03 upstream.
    
    The 32-bit ARM kernel stops working if the kernel grows to the point
    where veneers for __get_user_* are created.
    
    AAPCS32 [1] states, "Register r12 (IP) may be used by a linker as a
    scratch register between a routine and any subroutine it calls. It
    can also be used within a routine to hold intermediate values between
    subroutine calls."
    
    However, bl instructions buried within the inline asm are unpredictable
    for compilers; hence, "ip" must be added to the clobber list.
    
    This becomes critical when veneers for __get_user_* are created because
    veneers use the ip register since commit 02e541db0540 ("ARM: 8323/1:
    force linker to use PIC veneers").
    
    [1]: https://github.com/ARM-software/abi-aa/blob/2023Q1/aapcs32/aapcs32.rst
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Cc: John Stultz <jstultz@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ASoC: ti: davinci-mcasp: Set min period size using FIFO config [+ + +]
Author: Jai Luthra <j-luthra@ti.com>
Date:   Tue Jun 11 18:02:56 2024 +0530

    ASoC: ti: davinci-mcasp: Set min period size using FIFO config
    
    [ Upstream commit c5dcf8ab10606e76c1d8a0ec77f27d84a392e874 ]
    
    The minimum period size was enforced to 64 as older devices integrating
    McASP with EDMA used an internal FIFO of 64 samples.
    
    With UDMA based platforms this internal McASP FIFO is optional, as the
    DMA engine internally does some buffering which is already accounted for
    when registering the platform. So we should read the actual FIFO
    configuration (txnumevt/rxnumevt) instead of hardcoding frames.min to
    64.
    
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Signed-off-by: Jai Luthra <j-luthra@ti.com>
    Link: https://lore.kernel.org/r/20240611-asoc_next-v3-2-fcfd84b12164@ti.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: ti: omap-hdmi: Fix too long driver name [+ + +]
Author: Primoz Fiser <primoz.fiser@norik.com>
Date:   Mon Jun 10 14:58:47 2024 +0200

    ASoC: ti: omap-hdmi: Fix too long driver name
    
    [ Upstream commit 524d3f126362b6033e92cbe107ae2158d7fbff94 ]
    
    Set driver name to "HDMI". This simplifies the code and gets rid of
    the following error messages:
    
      ASoC: driver name too long 'HDMI 58040000.encoder' -> 'HDMI_58040000_e'
    
    Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Link: https://lore.kernel.org/r/20240610125847.773394-1-primoz.fiser@norik.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: hci_core: cancel all works upon hci_unregister_dev() [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Jun 10 20:00:32 2024 +0900

    Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
    
    [ Upstream commit 0d151a103775dd9645c78c97f77d6e2a5298d913 ]
    
    syzbot is reporting that calling hci_release_dev() from hci_error_reset()
    due to hci_dev_put() from hci_error_reset() can cause deadlock at
    destroy_workqueue(), for hci_error_reset() is called from
    hdev->req_workqueue which destroy_workqueue() needs to flush.
    
    We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are
    queued into hdev->workqueue and hdev->{power_on,error_reset} which are
    queued into hdev->req_workqueue are no longer running by the moment
    
           destroy_workqueue(hdev->workqueue);
           destroy_workqueue(hdev->req_workqueue);
    
    are called from hci_release_dev().
    
    Call cancel_work_sync() on these work items from hci_unregister_dev()
    as soon as hdev->list is removed from hci_dev_list.
    
    Reported-by: syzbot <syzbot+da0a9c9721e36db712e8@syzkaller.appspotmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=da0a9c9721e36db712e8
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue [+ + +]
Author: Jason Xing <kernelxing@tencent.com>
Date:   Thu Apr 4 10:10:01 2024 +0800

    bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
    
    commit 6648e613226e18897231ab5e42ffc29e63fa3365 upstream.
    
    Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which
    syzbot reported [1].
    
    [1]
    BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue
    
    write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:
     sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]
     sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843
     sk_psock_put include/linux/skmsg.h:459 [inline]
     sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648
     unix_release+0x4b/0x80 net/unix/af_unix.c:1048
     __sock_release net/socket.c:659 [inline]
     sock_close+0x68/0x150 net/socket.c:1421
     __fput+0x2c1/0x660 fs/file_table.c:422
     __fput_sync+0x44/0x60 fs/file_table.c:507
     __do_sys_close fs/open.c:1556 [inline]
     __se_sys_close+0x101/0x1b0 fs/open.c:1541
     __x64_sys_close+0x1f/0x30 fs/open.c:1541
     do_syscall_64+0xd3/0x1d0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:
     sk_psock_data_ready include/linux/skmsg.h:464 [inline]
     sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555
     sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606
     sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]
     sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202
     unix_read_skb net/unix/af_unix.c:2546 [inline]
     unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682
     sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223
     unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0x140/0x180 net/socket.c:745
     ____sys_sendmsg+0x312/0x410 net/socket.c:2584
     ___sys_sendmsg net/socket.c:2638 [inline]
     __sys_sendmsg+0x1e9/0x280 net/socket.c:2667
     __do_sys_sendmsg net/socket.c:2676 [inline]
     __se_sys_sendmsg net/socket.c:2674 [inline]
     __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674
     do_syscall_64+0xd3/0x1d0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    value changed: 0xffffffff83d7feb0 -> 0x0000000000000000
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G        W          6.8.0-syzkaller-08951-gfe46a7dd189e #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    
    Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer
    dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer
    similarly due to no protection of saved_data_ready. Here is another
    different caller causing the same issue because of the same reason. So
    we should protect it with sk_callback_lock read lock because the writer
    side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".
    
    To avoid errors that could happen in future, I move those two pairs of
    lock into the sk_psock_data_ready(), which is suggested by John Fastabend.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Reported-by: syzbot+aa8c8ec2538929f18f2d@syzkaller.appspotmail.com
    Signed-off-by: Jason Xing <kernelxing@tencent.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=aa8c8ec2538929f18f2d
    Link: https://lore.kernel.org/all/20240329134037.92124-1-kerneljasonxing@gmail.com
    Link: https://lore.kernel.org/bpf/20240404021001.94815-1-kerneljasonxing@gmail.com
    Signed-off-by: Ashwin Dayanand Kamat <ashwin.kamat@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bpf: Fix overrunning reservations in ringbuf [+ + +]
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Jun 21 16:08:27 2024 +0200

    bpf: Fix overrunning reservations in ringbuf
    
    commit cfa1a2329a691ffd991fcf7248a57d752e712881 upstream.
    
    The BPF ring buffer internally is implemented as a power-of-2 sized circular
    buffer, with two logical and ever-increasing counters: consumer_pos is the
    consumer counter to show which logical position the consumer consumed the
    data, and producer_pos which is the producer counter denoting the amount of
    data reserved by all producers.
    
    Each time a record is reserved, the producer that "owns" the record will
    successfully advance producer counter. In user space each time a record is
    read, the consumer of the data advanced the consumer counter once it finished
    processing. Both counters are stored in separate pages so that from user
    space, the producer counter is read-only and the consumer counter is read-write.
    
    One aspect that simplifies and thus speeds up the implementation of both
    producers and consumers is how the data area is mapped twice contiguously
    back-to-back in the virtual memory, allowing to not take any special measures
    for samples that have to wrap around at the end of the circular buffer data
    area, because the next page after the last data page would be first data page
    again, and thus the sample will still appear completely contiguous in virtual
    memory.
    
    Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for
    book-keeping the length and offset, and is inaccessible to the BPF program.
    Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`
    for the BPF program to use. Bing-Jhong and Muhammad reported that it is however
    possible to make a second allocated memory chunk overlapping with the first
    chunk and as a result, the BPF program is now able to edit first chunk's
    header.
    
    For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size
    of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to
    bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in
    [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets
    allocate a chunk B with size 0x3000. This will succeed because consumer_pos
    was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`
    check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able
    to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned
    earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data
    pages. This means that chunk B at [0x4000,0x4008] is chunk A's header.
    bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then
    locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk
    B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong
    page and could cause a crash.
    
    Fix it by calculating the oldest pending_pos and check whether the range
    from the oldest outstanding record to the newest would span beyond the ring
    buffer size. If that is the case, then reject the request. We've tested with
    the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)
    before/after the fix and while it seems a bit slower on some benchmarks, it
    is still not significantly enough to matter.
    
    Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it")
    Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
    Reported-by: Muhammad Ramdhan <ramdhan@starlabs.sg>
    Co-developed-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
    Co-developed-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20240621140828.18238-1-daniel@iogearbox.net
    Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
btrfs: qgroup: fix quota root leak after quota disable failure [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jun 20 12:32:00 2024 +0100

    btrfs: qgroup: fix quota root leak after quota disable failure
    
    [ Upstream commit a7e4c6a3031c74078dba7fa36239d0f4fe476c53 ]
    
    If during the quota disable we fail when cleaning the quota tree or when
    deleting the root from the root tree, we jump to the 'out' label without
    ever dropping the reference on the quota root, resulting in a leak of the
    root since fs_info->quota_root is no longer pointing to the root (we have
    set it to NULL just before those steps).
    
    Fix this by always doing a btrfs_put_root() call under the 'out' label.
    This is a problem that exists since qgroups were first added in 2012 by
    commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but
    back then we missed a kfree on the quota root and free_extent_buffer()
    calls on its root and commit root nodes, since back then roots were not
    yet reference counted.
    
    Reviewed-by: Boris Burkov <boris@bur.io>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bytcr_rt5640 : inverse jack detect for Archos 101 cesium [+ + +]
Author: Thomas GENTY <tomlohave@gmail.com>
Date:   Sat Jun 8 19:02:51 2024 +0200

    bytcr_rt5640 : inverse jack detect for Archos 101 cesium
    
    [ Upstream commit e3209a1827646daaab744aa6a5767b1f57fb5385 ]
    
    When headphones are plugged in, they appear absent; when they are removed,
    they appear present.
    Add a specific entry in bytcr_rt5640 for this device
    
    Signed-off-by: Thomas GENTY <tomlohave@gmail.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20240608170251.99936-1-tomlohave@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
can: kvaser_usb: fix return value for hif_usb_send_regout [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Tue May 21 12:10:20 2024 +0800

    can: kvaser_usb: fix return value for hif_usb_send_regout
    
    [ Upstream commit 0d34d8163fd87978a6abd792e2d8ad849f4c3d57 ]
    
    As the potential failure of usb_submit_urb(), it should be better to
    return the err variable to catch the error.
    
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Link: https://lore.kernel.org/all/20240521041020.1519416-1-nichen@iscas.ac.cn
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sun Apr 28 15:57:00 2024 +0300

    drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()
    
    commit 6769a23697f17f9bf9365ca8ed62fe37e361a05a upstream.
    
    The "instance" variable needs to be signed for the error handling to work.
    
    Fixes: 8b2faf1a4f3b ("drm/amdgpu: add error handle to avoid out-of-bounds")
    Reviewed-by: Bob Zhou <bob.zhou@amd.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: Siddh Raman Pant <siddh.raman.pant@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ext4: fix error code saved on super block during file system abort [+ + +]
Author: Gabriel Krisman Bertazi <krisman@collabora.com>
Date:   Tue Oct 26 14:33:02 2021 -0300

    ext4: fix error code saved on super block during file system abort
    
    commit 124e7c61deb27d758df5ec0521c36cf08d417f7a upstream.
    
    ext4_abort will eventually call ext4_errno_to_code, which translates the
    errno to an EXT4_ERR specific error.  This means that ext4_abort expects
    an errno.  By using EXT4_ERR_ here, it gets misinterpreted (as an errno),
    and ends up saving EXT4_ERR_EBUSY on the superblock during an abort,
    which makes no sense.
    
    ESHUTDOWN will get properly translated to EXT4_ERR_SHUTDOWN, so use that
    instead.
    
    Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
    Link: https://lore.kernel.org/r/20211026173302.84000-1-krisman@collabora.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: Send notifications on error [+ + +]
Author: Gabriel Krisman Bertazi <krisman@collabora.com>
Date:   Mon Oct 25 16:27:44 2021 -0300

    ext4: Send notifications on error
    
    commit 9a089b21f79b47eed240d4da7ea0d049de7c9b4d upstream.
    
    Send a FS_ERROR message via fsnotify to a userspace monitoring tool
    whenever a ext4 error condition is triggered.  This follows the existing
    error conditions in ext4, so it is hooked to the ext4_error* functions.
    
    Link: https://lore.kernel.org/r/20211025192746.66445-30-krisman@collabora.com
    Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
    Acked-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Jan Kara <jack@suse.cz>
    [Ajay: - Modified to apply on v5.10.y
           - Added fsnotify for __ext4_abort()]
    Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
filelock: Fix fcntl/close race recovery compat path [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Tue Jul 23 17:03:56 2024 +0200

    filelock: Fix fcntl/close race recovery compat path
    
    commit f8138f2ad2f745b9a1c696a05b749eabe44337ea upstream.
    
    When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when
    fcntl/close race is detected"), I missed that there are two copies of the
    code I was patching: The normal version, and the version for 64-bit offsets
    on 32-bit kernels.
    Thanks to Greg KH for stumbling over this while doing the stable
    backport...
    
    Apply exactly the same fix to the compat path for 32-bit kernels.
    
    Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling")
    Cc: stable@kernel.org
    Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563
    Signed-off-by: Jann Horn <jannh@google.com>
    Link: https://lore.kernel.org/r/20240723-fs-lock-recover-compatfix-v1-1-148096719529@google.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

filelock: Remove locks reliably when fcntl/close race is detected [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Tue Jul 2 18:26:52 2024 +0200

    filelock: Remove locks reliably when fcntl/close race is detected
    
    commit 3cad1bc010416c6dd780643476bc59ed742436b9 upstream.
    
    When fcntl_setlk() races with close(), it removes the created lock with
    do_lock_file_wait().
    However, LSMs can allow the first do_lock_file_wait() that created the lock
    while denying the second do_lock_file_wait() that tries to remove the lock.
    In theory (but AFAIK not in practice), posix_lock_file() could also fail to
    remove a lock due to GFP_KERNEL allocation failure (when splitting a range
    in the middle).
    
    After the bug has been triggered, use-after-free reads will occur in
    lock_get_status() when userspace reads /proc/locks. This can likely be used
    to read arbitrary kernel memory, but can't corrupt kernel memory.
    This only affects systems with SELinux / Smack / AppArmor / BPF-LSM in
    enforcing mode and only works from some security contexts.
    
    Fix it by calling locks_remove_posix() instead, which is designed to
    reliably get rid of POSIX locks associated with the given file and
    files_struct and is also used by filp_flush().
    
    Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling")
    Cc: stable@kernel.org
    Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563
    Signed-off-by: Jann Horn <jannh@google.com>
    Link: https://lore.kernel.org/r/20240702-fs-lock-recover-2-v1-1-edd456f63789@google.com
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    [stable fixup: ->c.flc_type was ->fl_type in older kernels]
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs/file: fix the check in find_next_fd() [+ + +]
Author: Yuntao Wang <yuntao.wang@linux.dev>
Date:   Thu May 30 00:06:56 2024 +0800

    fs/file: fix the check in find_next_fd()
    
    [ Upstream commit ed8c7fbdfe117abbef81f65428ba263118ef298a ]
    
    The maximum possible return value of find_next_zero_bit(fdt->full_fds_bits,
    maxbit, bitbit) is maxbit. This return value, multiplied by BITS_PER_LONG,
    gives the value of bitbit, which can never be greater than maxfd, it can
    only be equal to maxfd at most, so the following check 'if (bitbit > maxfd)'
    will never be true.
    
    Moreover, when bitbit equals maxfd, it indicates that there are no unused
    fds, and the function can directly return.
    
    Fix this check.
    
    Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev>
    Link: https://lore.kernel.org/r/20240529160656.209352-1-yuntao.wang@linux.dev
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs: better handle deep ancestor chains in is_subdir() [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Tue Jul 2 21:03:26 2024 +0200

    fs: better handle deep ancestor chains in is_subdir()
    
    [ Upstream commit 391b59b045004d5b985d033263ccba3e941a7740 ]
    
    Jan reported that 'cd ..' may take a long time in deep directory
    hierarchies under a bind-mount. If concurrent renames happen it is
    possible to livelock in is_subdir() because it will keep retrying.
    
    Change is_subdir() from simply retrying over and over to retry once and
    then acquire the rename lock to handle deep ancestor chains better. The
    list of alternatives to this approach were less then pleasant. Change
    the scope of rcu lock to cover the whole walk while at it.
    
    A big thanks to Jan and Linus. Both Jan and Linus had proposed
    effectively the same thing just that one version ended up being slightly
    more elegant.
    
    Reported-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gcc-plugins: Rename last_stmt() for GCC 14+ [+ + +]
Author: Kees Cook <kees@kernel.org>
Date:   Mon Aug 7 09:41:19 2023 -0700

    gcc-plugins: Rename last_stmt() for GCC 14+
    
    commit 2e3f65ccfe6b0778b261ad69c9603ae85f210334 upstream.
    
    In GCC 14, last_stmt() was renamed to last_nondebug_stmt(). Add a helper
    macro to handle the renaming.
    
    Cc: linux-hardening@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Thomas Meyer <thomas@m3y3r.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
hfsplus: fix uninit-value in copy_name [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Tue May 21 13:21:46 2024 +0800

    hfsplus: fix uninit-value in copy_name
    
    [ Upstream commit 0570730c16307a72f8241df12363f76600baf57d ]
    
    [syzbot reported]
    BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160
     sized_strscpy+0xc4/0x160
     copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411
     hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750
     vfs_listxattr fs/xattr.c:493 [inline]
     listxattr+0x1f3/0x6b0 fs/xattr.c:840
     path_listxattr fs/xattr.c:864 [inline]
     __do_sys_listxattr fs/xattr.c:876 [inline]
     __se_sys_listxattr fs/xattr.c:873 [inline]
     __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
     x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was created at:
     slab_post_alloc_hook mm/slub.c:3877 [inline]
     slab_alloc_node mm/slub.c:3918 [inline]
     kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065
     kmalloc include/linux/slab.h:628 [inline]
     hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699
     vfs_listxattr fs/xattr.c:493 [inline]
     listxattr+0x1f3/0x6b0 fs/xattr.c:840
     path_listxattr fs/xattr.c:864 [inline]
     __do_sys_listxattr fs/xattr.c:876 [inline]
     __se_sys_listxattr fs/xattr.c:873 [inline]
     __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
     x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    [Fix]
    When allocating memory to strbuf, initialize memory to 0.
    
    Reported-and-tested-by: syzbot+efde959319469ff8d4d7@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Link: https://lore.kernel.org/r/tencent_8BBB6433BC9E1C1B7B4BDF1BF52574BA8808@qq.com
    Reported-and-tested-by: syzbot+01ade747b16e9c8030e0@syzkaller.appspotmail.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ila: block BH in ila_output() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 31 13:26:35 2024 +0000

    ila: block BH in ila_output()
    
    [ Upstream commit cf28ff8e4c02e1ffa850755288ac954b6ff0db8c ]
    
    As explained in commit 1378817486d6 ("tipc: block BH
    before using dst_cache"), net/core/dst_cache.c
    helpers need to be called with BH disabled.
    
    ila_output() is called from lwtunnel_output()
    possibly from process context, and under rcu_read_lock().
    
    We might be interrupted by a softirq, re-enter ila_output()
    and corrupt dst_cache data structures.
    
    Fix the race by using local_bh_disable().
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/20240531132636.2637995-5-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: elantech - fix touchpad state on resume for Lenovo N24 [+ + +]
Author: Jonathan Denose <jdenose@google.com>
Date:   Fri May 3 16:12:07 2024 +0000

    Input: elantech - fix touchpad state on resume for Lenovo N24
    
    [ Upstream commit a69ce592cbe0417664bc5a075205aa75c2ec1273 ]
    
    The Lenovo N24 on resume becomes stuck in a state where it
    sends incorrect packets, causing elantech_packet_check_v4 to fail.
    The only way for the device to resume sending the correct packets is for
    it to be disabled and then re-enabled.
    
    This change adds a dmi check to trigger this behavior on resume.
    
    Signed-off-by: Jonathan Denose <jdenose@google.com>
    Link: https://lore.kernel.org/r/20240503155020.v2.1.Ifa0e25ebf968d8f307f58d678036944141ab17e6@changeid
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: i8042 - add Ayaneo Kun to i8042 quirk table [+ + +]
Author: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Date:   Fri May 31 15:43:07 2024 -0700

    Input: i8042 - add Ayaneo Kun to i8042 quirk table
    
    [ Upstream commit 955af6355ddfe35140f9706a635838212a32513b ]
    
    See the added comment for details. Also fix a typo in the
    quirk's define.
    
    Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
    Link: https://lore.kernel.org/r/20240531190100.3874731-1-tjakobi@math.uni-bielefeld.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: silead - Always support 10 fingers [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat May 25 21:38:53 2024 +0200

    Input: silead - Always support 10 fingers
    
    [ Upstream commit 38a38f5a36da9820680d413972cb733349400532 ]
    
    When support for Silead touchscreens was orginal added some touchscreens
    with older firmware versions only supported 5 fingers and this was made
    the default requiring the setting of a "silead,max-fingers=10" uint32
    device-property for all touchscreen models which do support 10 fingers.
    
    There are very few models with the old 5 finger fw, so in practice the
    setting of the "silead,max-fingers=10" is boilerplate which needs to
    be copy and pasted to every touchscreen config.
    
    Reporting that 10 fingers are supported on devices which only support
    5 fingers doesn't cause any problems for userspace in practice, since
    at max 4 finger gestures are supported anyways. Drop the max_fingers
    configuration and simply always assume 10 fingers.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Link: https://lore.kernel.org/r/20240525193854.39130-2-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jfs: don't walk off the end of ealist [+ + +]
Author: lei lu <llfamsec@gmail.com>
Date:   Wed May 29 02:30:40 2024 +0800

    jfs: don't walk off the end of ealist
    
    commit d0fa70aca54c8643248e89061da23752506ec0d4 upstream.
    
    Add a check before visiting the members of ea to
    make sure each ea stays within the ealist.
    
    Signed-off-by: lei lu <llfamsec@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kconfig: gconf: give a proper initial state to the Save button [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun Jun 2 03:20:40 2024 +0900

    kconfig: gconf: give a proper initial state to the Save button
    
    [ Upstream commit 46edf4372e336ef3a61c3126e49518099d2e2e6d ]
    
    Currently, the initial state of the "Save" button is always active.
    
    If none of the CONFIG options are changed while loading the .config
    file, the "Save" button should be greyed out.
    
    This can be fixed by calling conf_read() after widget initialization.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

kconfig: remove wrong expr_trans_bool() [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Jun 4 01:19:04 2024 +0900

    kconfig: remove wrong expr_trans_bool()
    
    [ Upstream commit 77a92660d8fe8d29503fae768d9f5eb529c88b36 ]
    
    expr_trans_bool() performs an incorrect transformation.
    
    [Test Code]
    
        config MODULES
                def_bool y
                modules
    
        config A
                def_bool y
                select C if B != n
    
        config B
                def_tristate m
    
        config C
                tristate
    
    [Result]
    
        CONFIG_MODULES=y
        CONFIG_A=y
        CONFIG_B=m
        CONFIG_C=m
    
    This output is incorrect because CONFIG_C=y is expected.
    
    Documentation/kbuild/kconfig-language.rst clearly explains the function
    of the '!=' operator:
    
        If the values of both symbols are equal, it returns 'n',
        otherwise 'y'.
    
    Therefore, the statement:
    
        select C if B != n
    
    should be equivalent to:
    
        select C if y
    
    Or, more simply:
    
        select C
    
    Hence, the symbol C should be selected by the value of A, which is 'y'.
    
    However, expr_trans_bool() wrongly transforms it to:
    
        select C if B
    
    Therefore, the symbol C is selected by (A && B), which is 'm'.
    
    The comment block of expr_trans_bool() correctly explains its intention:
    
      * bool FOO!=n => FOO
        ^^^^
    
    If FOO is bool, FOO!=n can be simplified into FOO. This is correct.
    
    However, the actual code performs this transformation when FOO is
    tristate:
    
        if (e->left.sym->type == S_TRISTATE) {
                                 ^^^^^^^^^^
    
    While it can be fixed to S_BOOLEAN, there is no point in doing so
    because expr_tranform() already transforms FOO!=n to FOO when FOO is
    bool. (see the "case E_UNEQUAL" part)
    
    expr_trans_bool() is wrong and unnecessary.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group() [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri Jun 14 22:29:10 2024 +1000

    KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()
    
    [ Upstream commit a986fa57fd81a1430e00b3c6cf8a325d6f894a63 ]
    
    Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().
    
    It looks up `stt` from tablefd, but then continues to use it after doing
    fdput() on the returned fd. After the fdput() the tablefd is free to be
    closed by another thread. The close calls kvm_spapr_tce_release() and
    then release_spapr_tce_table() (via call_rcu()) which frees `stt`.
    
    Although there are calls to rcu_read_lock() in
    kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
    the UAF, because `stt` is used outside the locked regions.
    
    With an artifcial delay after the fdput() and a userspace program which
    triggers the race, KASAN detects the UAF:
    
      BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
      Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505
      CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1
      Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
      Call Trace:
        dump_stack_lvl+0xb4/0x108 (unreliable)
        print_report+0x2b4/0x6ec
        kasan_report+0x118/0x2b0
        __asan_load4+0xb8/0xd0
        kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
        kvm_vfio_set_attr+0x524/0xac0 [kvm]
        kvm_device_ioctl+0x144/0x240 [kvm]
        sys_ioctl+0x62c/0x1810
        system_call_exception+0x190/0x440
        system_call_vectored_common+0x15c/0x2ec
      ...
      Freed by task 0:
       ...
       kfree+0xec/0x3e0
       release_spapr_tce_table+0xd4/0x11c [kvm]
       rcu_core+0x568/0x16a0
       handle_softirqs+0x23c/0x920
       do_softirq_own_stack+0x6c/0x90
       do_softirq_own_stack+0x58/0x90
       __irq_exit_rcu+0x218/0x2d0
       irq_exit+0x30/0x80
       arch_local_irq_restore+0x128/0x230
       arch_local_irq_enable+0x1c/0x30
       cpuidle_enter_state+0x134/0x5cc
       cpuidle_enter+0x6c/0xb0
       call_cpuidle+0x7c/0x100
       do_idle+0x394/0x410
       cpu_startup_entry+0x60/0x70
       start_secondary+0x3fc/0x410
       start_secondary_prolog+0x10/0x14
    
    Fix it by delaying the fdput() until `stt` is no longer in use, which
    is effectively the entire function. To keep the patch minimal add a call
    to fdput() at each of the existing return paths. Future work can convert
    the function to goto or __cleanup style cleanup.
    
    With the fix in place the test case no longer triggers the UAF.
    
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Closes: https://lore.kernel.org/all/20240610024437.GA1464458@ZenIV/
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240614122910.3499489-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.10.223 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jul 27 10:40:24 2024 +0200

    Linux 5.10.223
    
    Link: https://lore.kernel.org/r/20240725142733.262322603@linuxfoundation.org
    Tested-by: ChromeOS CQ Test <chromeos-kernel-stable-merge@google.com>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mei: demote client disconnect warning on suspend to debug [+ + +]
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Thu May 30 12:14:15 2024 +0300

    mei: demote client disconnect warning on suspend to debug
    
    [ Upstream commit 1db5322b7e6b58e1b304ce69a50e9dca798ca95b ]
    
    Change level for the "not connected" client message in the write
    callback from error to debug.
    
    The MEI driver currently disconnects all clients upon system suspend.
    This behavior is by design and user-space applications with
    open connections before the suspend are expected to handle errors upon
    resume, by reopening their handles, reconnecting,
    and retrying their operations.
    
    However, the current driver implementation logs an error message every
    time a write operation is attempted on a disconnected client.
    Since this is a normal and expected flow after system resume
    logging this as an error can be misleading.
    
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20240530091415.725247-1-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mips: fix compat_sys_lseek syscall [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Jun 20 18:23:04 2024 +0200

    mips: fix compat_sys_lseek syscall
    
    [ Upstream commit 0d5679a0aae2d8cda72169452c32e5cb88a7ab33 ]
    
    This is almost compatible, but passing a negative offset should result
    in a EINVAL error, but on mips o32 compat mode would seek to a large
    32-bit byte offset.
    
    Use compat_sys_lseek() to correctly sign-extend the argument.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: ipv6: rpl_iptunnel: block BH in rpl_output() and rpl_input() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 31 13:26:33 2024 +0000

    net: ipv6: rpl_iptunnel: block BH in rpl_output() and rpl_input()
    
    [ Upstream commit db0090c6eb12c31246438b7fe2a8f1b833e7a653 ]
    
    As explained in commit 1378817486d6 ("tipc: block BH
    before using dst_cache"), net/core/dst_cache.c
    helpers need to be called with BH disabled.
    
    Disabling preemption in rpl_output() is not good enough,
    because rpl_output() is called from process context,
    lwtunnel_output() only uses rcu_read_lock().
    
    We might be interrupted by a softirq, re-enter rpl_output()
    and corrupt dst_cache data structures.
    
    Fix the race by using local_bh_disable() instead of
    preempt_disable().
    
    Apply a similar change in rpl_input().
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Aring <aahringo@redhat.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/20240531132636.2637995-3-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD() [+ + +]
Author: Yunshui Jiang <jiangyunshui@kylinos.cn>
Date:   Fri May 31 16:07:39 2024 +0800

    net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD()
    
    [ Upstream commit b8ec0dc3845f6c9089573cb5c2c4b05f7fc10728 ]
    
    mac802154 devices update their dev->stats fields locklessly. Therefore
    these counters should be updated atomically. Adopt SMP safe DEV_STATS_INC()
    and DEV_STATS_ADD() to achieve this.
    
    Signed-off-by: Yunshui Jiang <jiangyunshui@kylinos.cn>
    Message-ID: <20240531080739.2608969-1-jiangyunshui@kylinos.cn>
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: relax socket state check at accept time. [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue May 21 16:01:00 2024 +0200

    net: relax socket state check at accept time.
    
    commit 26afda78cda3da974fd4c287962c169e9462c495 upstream.
    
    Christoph reported the following splat:
    
    WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0
    Modules linked in:
    CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
    RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759
    Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80
    RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293
    RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64
    R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000
    R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800
    FS:  000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786
     do_accept+0x435/0x620 net/socket.c:1929
     __sys_accept4_file net/socket.c:1969 [inline]
     __sys_accept4+0x9b/0x110 net/socket.c:1999
     __do_sys_accept net/socket.c:2016 [inline]
     __se_sys_accept net/socket.c:2013 [inline]
     __x64_sys_accept+0x7d/0x90 net/socket.c:2013
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    RIP: 0033:0x4315f9
    Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
    RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
    RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300
    R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055
     </TASK>
    
    The reproducer invokes shutdown() before entering the listener status.
    After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for
    TCP_SYN_RECV sockets"), the above causes the child to reach the accept
    syscall in FIN_WAIT1 status.
    
    Eric noted we can relax the existing assertion in __inet_accept()
    
    Reported-by: Christoph Paasch <cpaasch@apple.com>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/490
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Fixes: 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets")
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/23ab880a44d8cfd967e84de8b93dbf48848e3d8c.1716299669.git.pabeni@redhat.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Nikolay Kuratov <kniv@yandex-team.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: qmi_wwan: add Telit FN912 compositions [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Tue Jun 25 12:22:36 2024 +0200

    net: usb: qmi_wwan: add Telit FN912 compositions
    
    [ Upstream commit 77453e2b015b5ced5b3f45364dd5a72dfc3bdecb ]
    
    Add the following Telit FN912 compositions:
    
    0x3000: rmnet + tty (AT/NMEA) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=07 Cnt=01 Dev#=  8 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=3000 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN912
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x3001: rmnet + tty (AT) + tty (diag) + DPL (data packet logging) + adb
    T:  Bus=03 Lev=01 Prnt=03 Port=07 Cnt=01 Dev#=  7 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=3001 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN912
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Link: https://patch.msgid.link/20240625102236.69539-1-dnlplm@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
null_blk: fix validation of block size [+ + +]
Author: Andreas Hindborg <a.hindborg@samsung.com>
Date:   Mon Jun 3 21:26:45 2024 +0200

    null_blk: fix validation of block size
    
    [ Upstream commit c462ecd659b5fce731f1d592285832fd6ad54053 ]
    
    Block size should be between 512 and PAGE_SIZE and be a power of 2. The current
    check does not validate this, so update the check.
    
    Without this patch, null_blk would Oops due to a null pointer deref when
    loaded with bs=1536 [1].
    
    Link: https://lore.kernel.org/all/87wmn8mocd.fsf@metaspace.dk/
    
    Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20240603192645.977968-1-nmi@metaspace.dk
    [axboe: remove unnecessary braces and != 0 check]
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ocfs2: add bounds checking to ocfs2_check_dir_entry() [+ + +]
Author: lei lu <llfamsec@gmail.com>
Date:   Wed Jun 26 18:44:33 2024 +0800

    ocfs2: add bounds checking to ocfs2_check_dir_entry()
    
    commit 255547c6bb8940a97eea94ef9d464ea5967763fb upstream.
    
    This adds sanity checks for ocfs2_dir_entry to make sure all members of
    ocfs2_dir_entry don't stray beyond valid memory region.
    
    Link: https://lkml.kernel.org/r/20240626104433.163270-1-llfamsec@gmail.com
    Signed-off-by: lei lu <llfamsec@gmail.com>
    Reviewed-by: Heming Zhao <heming.zhao@suse.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/eeh: avoid possible crash when edev->pdev changes [+ + +]
Author: Ganesh Goudar <ganeshgr@linux.ibm.com>
Date:   Mon Jun 17 19:32:40 2024 +0530

    powerpc/eeh: avoid possible crash when edev->pdev changes
    
    [ Upstream commit a1216e62d039bf63a539bbe718536ec789a853dd ]
    
    If a PCI device is removed during eeh_pe_report_edev(), edev->pdev
    will change and can cause a crash, hold the PCI rescan/remove lock
    while taking a copy of edev->pdev->bus.
    
    Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240617140240.580453-1-ganeshgr@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries: Whitelist dtl slub object for copying to userspace [+ + +]
Author: Anjali K <anjalik@linux.ibm.com>
Date:   Fri Jun 14 23:08:44 2024 +0530

    powerpc/pseries: Whitelist dtl slub object for copying to userspace
    
    [ Upstream commit 1a14150e1656f7a332a943154fc486504db4d586 ]
    
    Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
    results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
    shown below.
    
        kernel BUG at mm/usercopy.c:102!
        Oops: Exception in kernel mode, sig: 5 [#1]
        LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
        Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
        scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
        CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
        Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
        NIP:  c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
        REGS: c000000120c078c0 TRAP: 0700   Not tainted  (6.10.0-rc3)
        MSR:  8000000000029033 <SF,EE,ME,IR,DR,RI,LE>  CR: 2828220f  XER: 0000000e
        CFAR: c0000000001fdc80 IRQMASK: 0
        [ ... GPRs omitted ... ]
        NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
        LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
        Call Trace:
         usercopy_abort+0x74/0xb0 (unreliable)
         __check_heap_object+0xf8/0x120
         check_heap_object+0x218/0x240
         __check_object_size+0x84/0x1a4
         dtl_file_read+0x17c/0x2c4
         full_proxy_read+0x8c/0x110
         vfs_read+0xdc/0x3a0
         ksys_read+0x84/0x144
         system_call_exception+0x124/0x330
         system_call_vectored_common+0x15c/0x2ec
        --- interrupt: 3000 at 0x7fff81f3ab34
    
    Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
    requires that only whitelisted areas in slab/slub objects can be copied to
    userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.
    Dtl contains hypervisor dispatch events which are expected to be read by
    privileged users. Hence mark this safe for user access.
    Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the
    entire object.
    
    Co-developed-by: Vishal Chourasia <vishalc@linux.ibm.com>
    Signed-off-by: Vishal Chourasia <vishalc@linux.ibm.com>
    Signed-off-by: Anjali K <anjalik@linux.ibm.com>
    Reviewed-by: Srikar Dronamraju <srikar@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240614173844.746818-1-anjalik@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/sclp: Fix sclp_init() cleanup on failure [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Fri Jun 14 18:09:01 2024 +0200

    s390/sclp: Fix sclp_init() cleanup on failure
    
    [ Upstream commit 6434b33faaa063df500af355ee6c3942e0f8d982 ]
    
    If sclp_init() fails it only partially cleans up: if there are multiple
    failing calls to sclp_init() sclp_state_change_event will be added several
    times to sclp_reg_list, which results in the following warning:
    
    ------------[ cut here ]------------
    list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.
    WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8
    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3
    Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)
               R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
    ...
    Call Trace:
     [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8
    ([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8)
     [<000003ffe0a8d37e>] sclp_init+0x40e/0x450
     [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0
     [<000003ffe15b77a6>] do_initcalls+0x126/0x150
     [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8
     [<000003ffe0d6650e>] kernel_init+0x2e/0x180
     [<000003ffe000301c>] __ret_from_fork+0x3c/0x60
     [<000003ffe0d759ca>] ret_from_fork+0xa/0x30
    
    Fix this by removing sclp_state_change_event from sclp_reg_list when
    sclp_init() fails.
    
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: core: Fix a use-after-free [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Aug 25 17:26:34 2022 -0700

    scsi: core: Fix a use-after-free
    
    commit 8fe4ce5836e932f5766317cb651c1ff2a4cd0506 upstream.
    
    There are two .exit_cmd_priv implementations. Both implementations use
    resources associated with the SCSI host. Make sure that these resources are
    still available when .exit_cmd_priv is called by waiting inside
    scsi_remove_host() until the tag set has been freed.
    
    This commit fixes the following use-after-free:
    
    ==================================================================
    BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]
    Read of size 8 at addr ffff888100337000 by task multipathd/16727
    Call Trace:
     <TASK>
     dump_stack_lvl+0x34/0x44
     print_report.cold+0x5e/0x5db
     kasan_report+0xab/0x120
     srp_exit_cmd_priv+0x27/0xd0 [ib_srp]
     scsi_mq_exit_request+0x4d/0x70
     blk_mq_free_rqs+0x143/0x410
     __blk_mq_free_map_and_rqs+0x6e/0x100
     blk_mq_free_tag_set+0x2b/0x160
     scsi_host_dev_release+0xf3/0x1a0
     device_release+0x54/0xe0
     kobject_put+0xa5/0x120
     device_release+0x54/0xe0
     kobject_put+0xa5/0x120
     scsi_device_dev_release_usercontext+0x4c1/0x4e0
     execute_in_process_context+0x23/0x90
     device_release+0x54/0xe0
     kobject_put+0xa5/0x120
     scsi_disk_release+0x3f/0x50
     device_release+0x54/0xe0
     kobject_put+0xa5/0x120
     disk_release+0x17f/0x1b0
     device_release+0x54/0xe0
     kobject_put+0xa5/0x120
     dm_put_table_device+0xa3/0x160 [dm_mod]
     dm_put_device+0xd0/0x140 [dm_mod]
     free_priority_group+0xd8/0x110 [dm_multipath]
     free_multipath+0x94/0xe0 [dm_multipath]
     dm_table_destroy+0xa2/0x1e0 [dm_mod]
     __dm_destroy+0x196/0x350 [dm_mod]
     dev_remove+0x10c/0x160 [dm_mod]
     ctl_ioctl+0x2c2/0x590 [dm_mod]
     dm_ctl_ioctl+0x5/0x10 [dm_mod]
     __x64_sys_ioctl+0xb4/0xf0
     dm_ctl_ioctl+0x5/0x10 [dm_mod]
     __x64_sys_ioctl+0xb4/0xf0
     do_syscall_64+0x3b/0x90
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Link: https://lore.kernel.org/r/20220826002635.919423-1-bvanassche@acm.org
    Fixes: 65ca846a5314 ("scsi: core: Introduce {init,exit}_cmd_priv()")
    Cc: Ming Lei <ming.lei@redhat.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Mike Christie <michael.christie@oracle.com>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: John Garry <john.garry@huawei.com>
    Cc: Li Zhijian <lizhijian@fujitsu.com>
    Reported-by: Li Zhijian <lizhijian@fujitsu.com>
    Tested-by: Li Zhijian <lizhijian@fujitsu.com>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [mheyne: fixed contextual conflicts:
      - drivers/scsi/hosts.c: due to missing commit 973dac8a8a14 ("scsi: core: Refine how we set tag_set NUMA node")
      - drivers/scsi/scsi_sysfs.c: due to missing commit 6f8191fdf41d ("block: simplify disk shutdown")
      - drivers/scsi/scsi_scan.c: due to missing commit 59506abe5e34 ("scsi: core: Inline scsi_mq_alloc_queue()")]
    Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: libsas: Fix exp-attached device scan after probe failure scanned in again after probe failed [+ + +]
Author: Xingui Yang <yangxingui@huawei.com>
Date:   Wed Jun 19 09:17:42 2024 +0000

    scsi: libsas: Fix exp-attached device scan after probe failure scanned in again after probe failed
    
    [ Upstream commit ab2068a6fb84751836a84c26ca72b3beb349619d ]
    
    The expander phy will be treated as broadcast flutter in the next
    revalidation after the exp-attached end device probe failed, as follows:
    
    [78779.654026] sas: broadcast received: 0
    [78779.654037] sas: REVALIDATING DOMAIN on port 0, pid:10
    [78779.654680] sas: ex 500e004aaaaaaa1f phy05 change count has changed
    [78779.662977] sas: ex 500e004aaaaaaa1f phy05 originated BROADCAST(CHANGE)
    [78779.662986] sas: ex 500e004aaaaaaa1f phy05 new device attached
    [78779.663079] sas: ex 500e004aaaaaaa1f phy05:U:8 attached: 500e004aaaaaaa05 (stp)
    [78779.693542] hisi_sas_v3_hw 0000:b4:02.0: dev[16:5] found
    [78779.701155] sas: done REVALIDATING DOMAIN on port 0, pid:10, res 0x0
    [78779.707864] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
    ...
    [78835.161307] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1
    [78835.171344] sas: sas_probe_sata: for exp-attached device 500e004aaaaaaa05 returned -19
    [78835.180879] hisi_sas_v3_hw 0000:b4:02.0: dev[16:5] is gone
    [78835.187487] sas: broadcast received: 0
    [78835.187504] sas: REVALIDATING DOMAIN on port 0, pid:10
    [78835.188263] sas: ex 500e004aaaaaaa1f phy05 change count has changed
    [78835.195870] sas: ex 500e004aaaaaaa1f phy05 originated BROADCAST(CHANGE)
    [78835.195875] sas: ex 500e004aaaaaaa1f rediscovering phy05
    [78835.196022] sas: ex 500e004aaaaaaa1f phy05:U:A attached: 500e004aaaaaaa05 (stp)
    [78835.196026] sas: ex 500e004aaaaaaa1f phy05 broadcast flutter
    [78835.197615] sas: done REVALIDATING DOMAIN on port 0, pid:10, res 0x0
    
    The cause of the problem is that the related ex_phy's attached_sas_addr was
    not cleared after the end device probe failed, so reset it.
    
    Signed-off-by: Xingui Yang <yangxingui@huawei.com>
    Link: https://lore.kernel.org/r/20240619091742.25465-1-yangxingui@huawei.com
    Reviewed-by: John Garry <john.g.garry@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qedf: Set qed_slowpath_params to zero before use [+ + +]
Author: Saurav Kashyap <skashyap@marvell.com>
Date:   Wed May 15 14:41:01 2024 +0530

    scsi: qedf: Set qed_slowpath_params to zero before use
    
    [ Upstream commit 6c3bb589debd763dc4b94803ddf3c13b4fcca776 ]
    
    Zero qed_slowpath_params before use.
    
    Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20240515091101.18754-4-skashyap@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/openat2: Fix build warnings on ppc64 [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue May 21 13:03:25 2024 +1000

    selftests/openat2: Fix build warnings on ppc64
    
    [ Upstream commit 84b6df4c49a1cc2854a16937acd5fd3e6315d083 ]
    
    Fix warnings like:
    
      openat2_test.c: In function ‘test_openat2_flags’:
      openat2_test.c:303:73: warning: format ‘%llX’ expects argument of type
      ‘long long unsigned int’, but argument 5 has type ‘__u64’ {aka ‘long
      unsigned int’} [-Wformat=]
    
    By switching to unsigned long long for u64 for ppc64 builds.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/vDSO: fix clang build errors and warnings [+ + +]
Author: John Hubbard <jhubbard@nvidia.com>
Date:   Fri Jul 5 09:57:34 2024 -1000

    selftests/vDSO: fix clang build errors and warnings
    
    [ Upstream commit 73810cd45b99c6c418e1c6a487b52c1e74edb20d ]
    
    When building with clang, via:
    
        make LLVM=1 -C tools/testing/selftests
    
    ...there are several warnings, and an error. This fixes all of those and
    allows these tests to run and pass.
    
    1. Fix linker error (undefined reference to memcpy) by providing a local
       version of memcpy.
    
    2. clang complains about using this form:
    
        if (g = h & 0xf0000000)
    
    ...so factor out the assignment into a separate step.
    
    3. The code is passing a signed const char* to elf_hash(), which expects
       a const unsigned char *. There are several callers, so fix this at
       the source by allowing the function to accept a signed argument, and
       then converting to unsigned operations, once inside the function.
    
    4. clang doesn't have __attribute__((externally_visible)) and generates
       a warning to that effect. Fortunately, gcc 12 and gcc 13 do not seem
       to require that attribute in order to build, run and pass tests here,
       so remove it.
    
    Reviewed-by: Carlos Llamas <cmllamas@google.com>
    Reviewed-by: Edward Liaw <edliaw@google.com>
    Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Tested-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Signed-off-by: John Hubbard <jhubbard@nvidia.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: imx: Don't expect DMA for i.MX{25,35,50,51,53} cspi devices [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed May 8 11:56:10 2024 +0200

    spi: imx: Don't expect DMA for i.MX{25,35,50,51,53} cspi devices
    
    [ Upstream commit ce1dac560a74220f2e53845ec0723b562288aed4 ]
    
    While in commit 2dd33f9cec90 ("spi: imx: support DMA for imx35") it was
    claimed that DMA works on i.MX25, i.MX31 and i.MX35 the respective
    device trees don't add DMA channels. The Reference manuals of i.MX31 and
    i.MX25 also don't mention the CSPI core being DMA capable. (I didn't
    check the others.)
    
    Since commit e267a5b3ec59 ("spi: spi-imx: Use dev_err_probe for failed
    DMA channel requests") this results in an error message
    
            spi_imx 43fa4000.spi: error -ENODEV: can't get the TX DMA channel!
    
    during boot. However that isn't fatal and the driver gets loaded just
    fine, just without using DMA.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://patch.msgid.link/20240508095610.2146640-2-u.kleine-koenig@pengutronix.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: mux: set ctlr->bits_per_word_mask [+ + +]
Author: David Lechner <dlechner@baylibre.com>
Date:   Mon Jul 8 20:05:30 2024 -0500

    spi: mux: set ctlr->bits_per_word_mask
    
    [ Upstream commit c8bd922d924bb4ab6c6c488310157d1a27996f31 ]
    
    Like other SPI controller flags, bits_per_word_mask may be used by a
    peripheral driver, so it needs to reflect the capabilities of the
    underlying controller.
    
    Signed-off-by: David Lechner <dlechner@baylibre.com>
    Link: https://patch.msgid.link/20240708-spi-mux-fix-v1-3-6c8845193128@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tap: add missing verification for short frame [+ + +]
Author: Si-Wei Liu <si-wei.liu@oracle.com>
Date:   Wed Jul 24 10:04:51 2024 -0700

    tap: add missing verification for short frame
    
    commit ed7f2afdd0e043a397677e597ced0830b83ba0b3 upstream.
    
    The cited commit missed to check against the validity of the frame length
    in the tap_get_user_xdp() path, which could cause a corrupted skb to be
    sent downstack. Even before the skb is transmitted, the
    tap_get_user_xdp()-->skb_set_network_header() may assume the size is more
    than ETH_HLEN. Once transmitted, this could either cause out-of-bound
    access beyond the actual length, or confuse the underlayer with incorrect
    or inconsistent header length in the skb metadata.
    
    In the alternative path, tap_get_user() already prohibits short frame which
    has the length less than Ethernet header size from being transmitted.
    
    This is to drop any frame shorter than the Ethernet header size just like
    how tap_get_user() does.
    
    CVE: CVE-2024-41090
    Link: https://lore.kernel.org/netdev/1717026141-25716-1-git-send-email-si-wei.liu@oracle.com/
    Fixes: 0efac27791ee ("tap: accept an array of XDP buffs through sendmsg()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
    Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Link: https://patch.msgid.link/20240724170452.16837-2-dongli.zhang@oracle.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tun: add missing verification for short frame [+ + +]
Author: Dongli Zhang <dongli.zhang@oracle.com>
Date:   Wed Jul 24 10:04:52 2024 -0700

    tun: add missing verification for short frame
    
    commit 049584807f1d797fc3078b68035450a9769eb5c3 upstream.
    
    The cited commit missed to check against the validity of the frame length
    in the tun_xdp_one() path, which could cause a corrupted skb to be sent
    downstack. Even before the skb is transmitted, the
    tun_xdp_one-->eth_type_trans() may access the Ethernet header although it
    can be less than ETH_HLEN. Once transmitted, this could either cause
    out-of-bound access beyond the actual length, or confuse the underlayer
    with incorrect or inconsistent header length in the skb metadata.
    
    In the alternative path, tun_get_user() already prohibits short frame which
    has the length less than Ethernet header size from being transmitted for
    IFF_TAP.
    
    This is to drop any frame shorter than the Ethernet header size just like
    how tun_get_user() does.
    
    CVE: CVE-2024-41091
    Inspired-by: https://lore.kernel.org/netdev/1717026141-25716-1-git-send-email-si-wei.liu@oracle.com/
    Fixes: 043d222f93ab ("tuntap: accept an array of XDP buffs through sendmsg()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
    Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Jason Wang <jasowang@redhat.com>
    Link: https://patch.msgid.link/20240724170452.16837-3-dongli.zhang@oracle.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: cfg80211: wext: add extra SIOCSIWSCAN data check [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Fri May 31 06:20:10 2024 +0300

    wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
    
    [ Upstream commit 6ef09cdc5ba0f93826c09d810c141a8d103a80fc ]
    
    In 'cfg80211_wext_siwscan()', add extra check whether number of
    channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed
    IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.
    
    Reported-by: syzbot+253cd2d2491df77c93ac@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=253cd2d2491df77c93ac
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Link: https://msgid.link/20240531032010.451295-1-dmantipov@yandex.ru
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix UBSAN noise in ieee80211_prep_hw_scan() [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Fri May 17 18:33:32 2024 +0300

    wifi: mac80211: fix UBSAN noise in ieee80211_prep_hw_scan()
    
    [ Upstream commit 92ecbb3ac6f3fe8ae9edf3226c76aa17b6800699 ]
    
    When testing the previous patch with CONFIG_UBSAN_BOUNDS, I've
    noticed the following:
    
    UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:372:4
    index 0 is out of range for type 'struct ieee80211_channel *[]'
    CPU: 0 PID: 1435 Comm: wpa_supplicant Not tainted 6.9.0+ #1
    Hardware name: LENOVO 20UN005QRT/20UN005QRT <...BIOS details...>
    Call Trace:
     <TASK>
     dump_stack_lvl+0x2d/0x90
     __ubsan_handle_out_of_bounds+0xe7/0x140
     ? timerqueue_add+0x98/0xb0
     ieee80211_prep_hw_scan+0x2db/0x480 [mac80211]
     ? __kmalloc+0xe1/0x470
     __ieee80211_start_scan+0x541/0x760 [mac80211]
     rdev_scan+0x1f/0xe0 [cfg80211]
     nl80211_trigger_scan+0x9b6/0xae0 [cfg80211]
     ...<the rest is not too useful...>
    
    Since '__ieee80211_start_scan()' leaves 'hw_scan_req->req.n_channels'
    uninitialized, actual boundaries of 'hw_scan_req->req.channels' can't
    be checked in 'ieee80211_prep_hw_scan()'. Although an initialization
    of 'hw_scan_req->req.n_channels' introduces some confusion around
    allocated vs. used VLA members, this shouldn't be a problem since
    everything is correctly adjusted soon in 'ieee80211_prep_hw_scan()'.
    
    Cleanup 'kmalloc()' math in '__ieee80211_start_scan()' by using the
    convenient 'struct_size()' as well.
    
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Link: https://msgid.link/20240517153332.18271-2-dmantipov@yandex.ru
    [improve (imho) indentation a bit]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: mesh: init nonpeer_pm to active by default in mesh sdata [+ + +]
Author: Nicolas Escande <nico.escande@gmail.com>
Date:   Mon May 27 16:17:59 2024 +0200

    wifi: mac80211: mesh: init nonpeer_pm to active by default in mesh sdata
    
    [ Upstream commit 6f6291f09a322c1c1578badac8072d049363f4e6 ]
    
    With a ath9k device I can see that:
            iw phy phy0 interface add mesh0 type mp
            ip link set mesh0 up
            iw dev mesh0 scan
    
    Will start a scan with the Power Management bit set in the Frame Control Field.
    This is because we set this bit depending on the nonpeer_pm variable of the mesh
    iface sdata and when there are no active links on the interface it remains to
    NL80211_MESH_POWER_UNKNOWN.
    
    As soon as links starts to be established, it wil switch to
    NL80211_MESH_POWER_ACTIVE as it is the value set by befault on the per sta
    nonpeer_pm field.
    As we want no power save by default, (as expressed with the per sta ini values),
    lets init it to the expected default value of NL80211_MESH_POWER_ACTIVE.
    
    Also please note that we cannot change the default value from userspace prior to
    establishing a link as using NL80211_CMD_SET_MESH_CONFIG will not work before
    NL80211_CMD_JOIN_MESH has been issued. So too late for our initial scan.
    
    Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
    Link: https://msgid.link/20240527141759.299411-1-nico.escande@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>