Changelog in Linux kernel 6.1.109

 
ALSA: hda/conexant: Mute speakers at suspend / shutdown [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jul 26 16:26:20 2024 +0200

    ALSA: hda/conexant: Mute speakers at suspend / shutdown
    
    [ Upstream commit 4f61c8fe35202702426cfc0003e15116a01ba885 ]
    
    Use the new helper to mute speakers at suspend / shutdown for avoiding
    click noises.
    
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1228269
    Link: https://patch.msgid.link/20240726142625.2460-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/generic: Add a helper to mute speakers at suspend/shutdown [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jul 26 16:26:19 2024 +0200

    ALSA: hda/generic: Add a helper to mute speakers at suspend/shutdown
    
    [ Upstream commit 6cd23b26b348fa52c88e1adf9c0e48d68e13f95e ]
    
    Some devices indicate click noises at suspend or shutdown when the
    speakers are unmuted.  This patch adds a helper,
    snd_hda_gen_shutup_speakers(), to work around it.  The new function is
    supposed to be called at suspend or shutdown by the codec driver, and
    it mutes the speakers.
    
    The mute status isn't cached, hence the original mute state will be
    restored at resume again.
    
    Link: https://patch.msgid.link/20240726142625.2460-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
apparmor: fix possible NULL pointer dereference [+ + +]
Author: Leesoo Ahn <lsahn@ooseel.net>
Date:   Wed May 8 01:12:29 2024 +0900

    apparmor: fix possible NULL pointer dereference
    
    [ Upstream commit 3dd384108d53834002be5630132ad5c3f32166ad ]
    
    profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made
    from __create_missing_ancestors(..) and 'ent->old' is NULL in
    aa_replace_profiles(..).
    In that case, it must return an error code and the code, -ENOENT represents
    its state that the path of its parent is not existed yet.
    
    BUG: kernel NULL pointer dereference, address: 0000000000000030
    PGD 0 P4D 0
    PREEMPT SMP PTI
    CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
    RIP: 0010:aafs_create.constprop.0+0x7f/0x130
    Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
    RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
    Call Trace:
     <TASK>
     ? show_regs+0x6d/0x80
     ? __die+0x24/0x80
     ? page_fault_oops+0x99/0x1b0
     ? kernelmode_fixup_or_oops+0xb2/0x140
     ? __bad_area_nosemaphore+0x1a5/0x2c0
     ? find_vma+0x34/0x60
     ? bad_area_nosemaphore+0x16/0x30
     ? do_user_addr_fault+0x2a2/0x6b0
     ? exc_page_fault+0x83/0x1b0
     ? asm_exc_page_fault+0x27/0x30
     ? aafs_create.constprop.0+0x7f/0x130
     ? aafs_create.constprop.0+0x51/0x130
     __aafs_profile_mkdir+0x3d6/0x480
     aa_replace_profiles+0x83f/0x1270
     policy_update+0xe3/0x180
     profile_load+0xbc/0x150
     ? rw_verify_area+0x47/0x140
     vfs_write+0x100/0x480
     ? __x64_sys_openat+0x55/0xa0
     ? syscall_exit_to_user_mode+0x86/0x260
     ksys_write+0x73/0x100
     __x64_sys_write+0x19/0x30
     x64_sys_call+0x7e/0x25c0
     do_syscall_64+0x7f/0x180
     entry_SYSCALL_64_after_hwframe+0x78/0x80
    RIP: 0033:0x7be9f211c574
    Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
    RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574
    RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004
    RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000
    R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80
    R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30
     </TASK>
    Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas
    CR2: 0000000000000030
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:aafs_create.constprop.0+0x7f/0x130
    Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
    RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
    
    Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: amd: yc: Support mic on Lenovo Thinkpad E14 Gen 6 [+ + +]
Author: Krzysztof Stępniak <kfs.szk@gmail.com>
Date:   Wed Aug 7 02:12:19 2024 +0200

    ASoC: amd: yc: Support mic on Lenovo Thinkpad E14 Gen 6
    
    [ Upstream commit 23a58b782f864951485d7a0018549729e007cb43 ]
    
    Lenovo Thinkpad E14 Gen 6 (model type 21M3)
    needs a quirk entry for internal mic to work.
    
    Signed-off-by: Krzysztof Stępniak <kfs.szk@gmail.com>
    Link: https://patch.msgid.link/20240807001219.1147-1-kfs.szk@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: remove the blk_flush_integrity call in blk_integrity_unregister [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Jun 13 10:48:16 2024 +0200

    block: remove the blk_flush_integrity call in blk_integrity_unregister
    
    [ Upstream commit e8bc14d116aeac8f0f133ec8d249acf4e0658da7 ]
    
    Now that there are no indirect calls for PI processing there is no
    way to dereference a NULL pointer here.  Additionally drivers now always
    freeze the queue (or in case of stacking drivers use their internal
    equivalent) around changing the integrity profile.
    
    This is effectively a revert of commit 3df49967f6f1 ("block: flush the
    integrity workqueue in blk_integrity_unregister").
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Link: https://lore.kernel.org/r/20240613084839.1044015-7-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Mar 30 14:15:50 2023 -0700

    Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm
    
    commit 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 upstream.
    
    This attempts to fix the following trace:
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.3.0-rc2-g0b93eeba4454 #4703 Not tainted
    ------------------------------------------------------
    kworker/u3:0/46 is trying to acquire lock:
    ffff888001fd9130 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at:
    sco_connect_cfm+0x118/0x4a0
    
    but task is already holding lock:
    ffffffff831e3340 (hci_cb_list_lock){+.+.}-{3:3}, at:
    hci_sync_conn_complete_evt+0x1ad/0x3d0
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (hci_cb_list_lock){+.+.}-{3:3}:
           __mutex_lock+0x13b/0xcc0
           hci_sync_conn_complete_evt+0x1ad/0x3d0
           hci_event_packet+0x55c/0x7c0
           hci_rx_work+0x34c/0xa00
           process_one_work+0x575/0x910
           worker_thread+0x89/0x6f0
           kthread+0x14e/0x180
           ret_from_fork+0x2b/0x50
    
    -> #1 (&hdev->lock){+.+.}-{3:3}:
           __mutex_lock+0x13b/0xcc0
           sco_sock_connect+0xfc/0x630
           __sys_connect+0x197/0x1b0
           __x64_sys_connect+0x37/0x50
           do_syscall_64+0x42/0x90
           entry_SYSCALL_64_after_hwframe+0x70/0xda
    
    -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
           __lock_acquire+0x18cc/0x3740
           lock_acquire+0x151/0x3a0
           lock_sock_nested+0x32/0x80
           sco_connect_cfm+0x118/0x4a0
           hci_sync_conn_complete_evt+0x1e6/0x3d0
           hci_event_packet+0x55c/0x7c0
           hci_rx_work+0x34c/0xa00
           process_one_work+0x575/0x910
           worker_thread+0x89/0x6f0
           kthread+0x14e/0x180
           ret_from_fork+0x2b/0x50
    
    other info that might help us debug this:
    
    Chain exists of:
      sk_lock-AF_BLUETOOTH-BTPROTO_SCO --> &hdev->lock --> hci_cb_list_lock
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(hci_cb_list_lock);
                                   lock(&hdev->lock);
                                   lock(hci_cb_list_lock);
      lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO);
    
     *** DEADLOCK ***
    
    4 locks held by kworker/u3:0/46:
     #0: ffff8880028d1130 ((wq_completion)hci0#2){+.+.}-{0:0}, at:
     process_one_work+0x4c0/0x910
     #1: ffff8880013dfde0 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0},
     at: process_one_work+0x4c0/0x910
     #2: ffff8880025d8070 (&hdev->lock){+.+.}-{3:3}, at:
     hci_sync_conn_complete_evt+0xa6/0x3d0
     #3: ffffffffb79e3340 (hci_cb_list_lock){+.+.}-{3:3}, at:
     hci_sync_conn_complete_evt+0x1ad/0x3d0
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: SCO: fix sco_conn related locking and validity issues [+ + +]
Author: Pauli Virtanen <pav@iki.fi>
Date:   Mon Jul 10 19:48:19 2023 +0300

    Bluetooth: SCO: fix sco_conn related locking and validity issues
    
    commit 3dcaa192ac2159193bc6ab57bc5369dcb84edd8e upstream.
    
    Operations that check/update sk_state and access conn should hold
    lock_sock, otherwise they can race.
    
    The order of taking locks is hci_dev_lock > lock_sock > sco_conn_lock,
    which is how it is in connect/disconnect_cfm -> sco_conn_del ->
    sco_chan_del.
    
    Fix locking in sco_connect to take lock_sock around updating sk_state
    and conn.
    
    sco_conn_del must not occur during sco_connect, as it frees the
    sco_conn. Hold hdev->lock longer to prevent that.
    
    sco_conn_add shall return sco_conn with valid hcon. Make it so also when
    reusing an old SCO connection waiting for disconnect timeout (see
    __sco_sock_close where conn->hcon is set to NULL).
    
    This should not reintroduce the issue fixed in the earlier
    commit 9a8ec9e8ebb5 ("Bluetooth: SCO: Fix possible circular locking
    dependency on sco_connect_cfm"), the relevant fix of releasing lock_sock
    in sco_sock_connect before acquiring hdev->lock is retained.
    
    These changes mirror similar fixes earlier in ISO sockets.
    
    Fixes: 9a8ec9e8ebb5 ("Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm")
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpufreq: scmi: Avoid overflow of target_freq in fast switch [+ + +]
Author: Jagadeesh Kona <quic_jkona@quicinc.com>
Date:   Mon May 20 12:07:32 2024 +0530

    cpufreq: scmi: Avoid overflow of target_freq in fast switch
    
    [ Upstream commit 074cffb5020ddcaa5fafcc55655e5da6ebe8c831 ]
    
    Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
    can lead to overflow if the multiplied result is greater than
    UINT_MAX, since type of target_freq is unsigned int. Avoid this
    overflow by assigning target_freq to unsigned long variable for
    converting it to HZ.
    
    Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dma-debug: avoid deadlock between dma debug vs printk and netconsole [+ + +]
Author: Rik van Riel <riel@surriel.com>
Date:   Tue Aug 6 11:56:45 2024 -0400

    dma-debug: avoid deadlock between dma debug vs printk and netconsole
    
    [ Upstream commit bd44ca3de49cc1badcff7a96010fa2c64f04868c ]
    
    Currently the dma debugging code can end up indirectly calling printk
    under the radix_lock. This happens when a radix tree node allocation
    fails.
    
    This is a problem because the printk code, when used together with
    netconsole, can end up inside the dma debugging code while trying to
    transmit a message over netcons.
    
    This creates the possibility of either a circular deadlock on the same
    CPU, with that CPU trying to grab the radix_lock twice, or an ABBA
    deadlock between different CPUs, where one CPU grabs the console lock
    first and then waits for the radix_lock, while the other CPU is holding
    the radix_lock and is waiting for the console lock.
    
    The trace captured by lockdep is of the ABBA variant.
    
    -> #2 (&dma_entry_hash[i].lock){-.-.}-{2:2}:
                      _raw_spin_lock_irqsave+0x5a/0x90
                      debug_dma_map_page+0x79/0x180
                      dma_map_page_attrs+0x1d2/0x2f0
                      bnxt_start_xmit+0x8c6/0x1540
                      netpoll_start_xmit+0x13f/0x180
                      netpoll_send_skb+0x20d/0x320
                      netpoll_send_udp+0x453/0x4a0
                      write_ext_msg+0x1b9/0x460
                      console_flush_all+0x2ff/0x5a0
                      console_unlock+0x55/0x180
                      vprintk_emit+0x2e3/0x3c0
                      devkmsg_emit+0x5a/0x80
                      devkmsg_write+0xfd/0x180
                      do_iter_readv_writev+0x164/0x1b0
                      vfs_writev+0xf9/0x2b0
                      do_writev+0x6d/0x110
                      do_syscall_64+0x80/0x150
                      entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    -> #0 (console_owner){-.-.}-{0:0}:
                      __lock_acquire+0x15d1/0x31a0
                      lock_acquire+0xe8/0x290
                      console_flush_all+0x2ea/0x5a0
                      console_unlock+0x55/0x180
                      vprintk_emit+0x2e3/0x3c0
                      _printk+0x59/0x80
                      warn_alloc+0x122/0x1b0
                      __alloc_pages_slowpath+0x1101/0x1120
                      __alloc_pages+0x1eb/0x2c0
                      alloc_slab_page+0x5f/0x150
                      new_slab+0x2dc/0x4e0
                      ___slab_alloc+0xdcb/0x1390
                      kmem_cache_alloc+0x23d/0x360
                      radix_tree_node_alloc+0x3c/0xf0
                      radix_tree_insert+0xf5/0x230
                      add_dma_entry+0xe9/0x360
                      dma_map_page_attrs+0x1d2/0x2f0
                      __bnxt_alloc_rx_frag+0x147/0x180
                      bnxt_alloc_rx_data+0x79/0x160
                      bnxt_rx_skb+0x29/0xc0
                      bnxt_rx_pkt+0xe22/0x1570
                      __bnxt_poll_work+0x101/0x390
                      bnxt_poll+0x7e/0x320
                      __napi_poll+0x29/0x160
                      net_rx_action+0x1e0/0x3e0
                      handle_softirqs+0x190/0x510
                      run_ksoftirqd+0x4e/0x90
                      smpboot_thread_fn+0x1a8/0x270
                      kthread+0x102/0x120
                      ret_from_fork+0x2f/0x40
                      ret_from_fork_asm+0x11/0x20
    
    This bug is more likely than it seems, because when one CPU has run out
    of memory, chances are the other has too.
    
    The good news is, this bug is hidden behind the CONFIG_DMA_API_DEBUG, so
    not many users are likely to trigger it.
    
    Signed-off-by: Rik van Riel <riel@surriel.com>
    Reported-by: Konstantin Ovsepian <ovs@meta.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor [+ + +]
Author: Olivier Dautricourt <olivierdautricourt@gmail.com>
Date:   Sat Jun 8 23:31:48 2024 +0200

    dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor
    
    [ Upstream commit 54e4ada1a4206f878e345ae01cf37347d803d1b1 ]
    
    Remove list_del call in msgdma_chan_desc_cleanup, this should be the role
    of msgdma_free_descriptor. In consequence replace list_add_tail with
    list_move_tail in msgdma_free_descriptor.
    
    This fixes the path:
       msgdma_free_chan_resources -> msgdma_free_descriptors ->
       msgdma_free_desc_list -> msgdma_free_descriptor
    
    which does not correctly free the descriptors as first nodes were not
    removed from the list.
    
    Signed-off-by: Olivier Dautricourt <olivierdautricourt@gmail.com>
    Tested-by: Olivier Dautricourt <olivierdautricourt@gmail.com>
    Link: https://lore.kernel.org/r/20240608213216.25087-3-olivierdautricourt@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: altera-msgdma: use irq variant of spin_lock/unlock while invoking callbacks [+ + +]
Author: Olivier Dautricourt <olivierdautricourt@gmail.com>
Date:   Sat Jun 8 23:31:46 2024 +0200

    dmaengine: altera-msgdma: use irq variant of spin_lock/unlock while invoking callbacks
    
    [ Upstream commit 261d3a85d959841821ca0d69f9d7b0d4087661c4 ]
    
    As we first take the lock with spin_lock_irqsave in msgdma_tasklet, Lockdep
    might complain about this. Inspired by commit 9558cf4ad07e
    ("dmaengine: zynqmp_dma: fix lockdep warning in tasklet")
    
    Signed-off-by: Olivier Dautricourt <olivierdautricourt@gmail.com>
    Tested-by: Olivier Dautricourt <olivierdautricourt@gmail.com>
    Suggested-by: Eric Schwarz <eas@sw-optimization.com>
    Link: https://lore.kernel.org/r/20240608213216.25087-1-olivierdautricourt@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
driver: iio: add missing checks on iio_info's callback access [+ + +]
Author: Julien Stephan <jstephan@baylibre.com>
Date:   Thu May 30 11:22:46 2024 +0200

    driver: iio: add missing checks on iio_info's callback access
    
    [ Upstream commit c4ec8dedca961db056ec85cb7ca8c9f7e2e92252 ]
    
    Some callbacks from iio_info structure are accessed without any check, so
    if a driver doesn't implement them trying to access the corresponding
    sysfs entries produce a kernel oops such as:
    
    [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute
    [...]
    [ 2203.783416] Call trace:
    [ 2203.783429]  iio_read_channel_info_avail from dev_attr_show+0x18/0x48
    [ 2203.789807]  dev_attr_show from sysfs_kf_seq_show+0x90/0x120
    [ 2203.794181]  sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4
    [ 2203.798555]  seq_read_iter from vfs_read+0x238/0x2a0
    [ 2203.802236]  vfs_read from ksys_read+0xa4/0xd4
    [ 2203.805385]  ksys_read from ret_fast_syscall+0x0/0x54
    [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)
    [ 2203.812880] dfa0:                   00000003 b6f10f80 00000003 b6eab000 00020000 00000000
    [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000
    [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0
    [ 2203.830363] Code: bad PC value
    [ 2203.832695] ---[ end trace 0000000000000000 ]---
    
    Reviewed-by: Nuno Sa <nuno.sa@analog.com>
    Signed-off-by: Julien Stephan <jstephan@baylibre.com>
    Link: https://lore.kernel.org/r/20240530-iio-core-fix-segfault-v3-1-8b7cd2a03773@baylibre.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/amdgpu: Check tbo resource pointer [+ + +]
Author: Asad Kamal <asad.kamal@amd.com>
Date:   Fri Apr 26 02:26:55 2024 +0800

    drm/amd/amdgpu: Check tbo resource pointer
    
    [ Upstream commit 6cd2b872643bb29bba01a8ac739138db7bd79007 ]
    
    Validate tbo resource pointer, skip if NULL
    
    Signed-off-by: Asad Kamal <asad.kamal@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Add array index check for hdcp ddc access [+ + +]
Author: Hersen Wu <hersenxs.wu@amd.com>
Date:   Wed Apr 24 10:09:31 2024 -0400

    drm/amd/display: Add array index check for hdcp ddc access
    
    [ Upstream commit 4e70c0f5251c25885c31ee84a31f99a01f7cf50e ]
    
    [Why]
    Coverity reports OVERRUN warning. Do not check if array
    index valid.
    
    [How]
    Check msg_id valid and valid array index.
    
    Reviewed-by: Alex Hung <alex.hung@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: added NULL check at start of dc_validate_stream [+ + +]
Author: winstang <winstang@amd.com>
Date:   Mon May 27 08:51:19 2024 -0400

    drm/amd/display: added NULL check at start of dc_validate_stream
    
    [ Upstream commit 26c56049cc4f1705b498df013949427692a4b0d5 ]
    
    [Why]
    prevent invalid memory access
    
    [How]
    check if dc and stream are NULL
    
    Co-authored-by: winstang <winstang@amd.com>
    Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
    Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
    Signed-off-by: winstang <winstang@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Assign linear_pitch_alignment even for VM [+ + +]
Author: Alvin Lee <alvin.lee2@amd.com>
Date:   Tue Apr 16 14:42:18 2024 -0400

    drm/amd/display: Assign linear_pitch_alignment even for VM
    
    [ Upstream commit 984debc133efa05e62f5aa1a7a1dd8ca0ef041f4 ]
    
    [Description]
    Assign linear_pitch_alignment so we don't cause a divide by 0
    error in VM environments
    
    Reviewed-by: Sohaib Nadeem <sohaib.nadeem@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Alvin Lee <alvin.lee2@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Check gpio_id before used as array index [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Apr 16 16:40:00 2024 -0600

    drm/amd/display: Check gpio_id before used as array index
    
    [ Upstream commit 2a5626eeb3b5eec7a36886f9556113dd93ec8ed6 ]
    
    [WHY & HOW]
    GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore
    should be checked in advance.
    
    This fixes 5 OVERRUN issues reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Check msg_id before processing transcation [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Apr 16 16:47:42 2024 -0600

    drm/amd/display: Check msg_id before processing transcation
    
    [ Upstream commit fa71face755e27dc44bc296416ebdf2c67163316 ]
    
    [WHY & HOW]
    HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid
    array index, and it needs checking before used.
    
    This fixes 4 OVERRUN issues reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[] [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Apr 16 16:22:35 2024 -0600

    drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]
    
    [ Upstream commit b38a4815f79b87efb196cd5121579fc51e29a7fb ]
    
    [WHY & HOW]
    num_valid_sets needs to be checked to avoid a negative index when
    accessing reader_wm_sets[num_valid_sets - 1].
    
    This fixes an OVERRUN issue reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [+ + +]
Author: Wayne Lin <wayne.lin@amd.com>
Date:   Mon May 27 15:33:48 2024 +0800

    drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX
    
    [ Upstream commit ad28d7c3d989fc5689581664653879d664da76f0 ]
    
    [Why & How]
    It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller
    number to create array dmub_callback & dmub_thread_offload has potential to access
    item out of array bound. Fix it.
    
    Reviewed-by: Jerry Zuo <jerry.zuo@amd.com>
    Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
    Signed-off-by: Wayne Lin <wayne.lin@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Ensure index calculation will not overflow [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Wed Apr 24 17:08:04 2024 -0600

    drm/amd/display: Ensure index calculation will not overflow
    
    [ Upstream commit 8e2734bf444767fed787305ccdcb36a2be5301a2 ]
    
    [WHY & HOW]
    Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will
    never overflow and exceess array size.
    
    This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix Coverity INTEGER_OVERFLOW within dal_gpio_service_create [+ + +]
Author: Hersen Wu <hersenxs.wu@amd.com>
Date:   Fri Apr 26 11:58:11 2024 -0400

    drm/amd/display: Fix Coverity INTEGER_OVERFLOW within dal_gpio_service_create
    
    [ Upstream commit c6077aa66fa230d12f37fef01161ef080d13b726 ]
    
    [Why]
    For subtraction, coverity reports integer overflow
    warning message when variable type is uint32_t.
    
    [How]
    Change variable type to int32_t.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration [+ + +]
Author: Hersen Wu <hersenxs.wu@amd.com>
Date:   Fri Apr 26 16:39:37 2024 -0400

    drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration
    
    [ Upstream commit a54f7e866cc73a4cb71b8b24bb568ba35c8969df ]
    
    [Why]
    Coverity reports Memory - illegal accesses.
    
    [How]
    Skip inactive planes.
    
    Reviewed-by: Alex Hung <alex.hung@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Skip wbscl_set_scaler_filter if filter is null [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Mon Jun 3 10:47:37 2024 -0600

    drm/amd/display: Skip wbscl_set_scaler_filter if filter is null
    
    [ Upstream commit c4d31653c03b90e51515b1380115d1aedad925dd ]
    
    Callers can pass null in filter (i.e. from returned from the function
    wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is
    not the case.
    
    This fixes 4 NULL_RETURNS issues reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Spinlock before reading event [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Fri Apr 26 10:33:47 2024 -0600

    drm/amd/display: Spinlock before reading event
    
    [ Upstream commit ae13c8a5cff92015b9a3eb7cee65ebc75859487f ]
    
    [WHY & HOW]
    A read of acrtc_attach->base.state->event was not locked so moving it
    inside the spinlock.
    
    This fixes a LOCK_EVASION issue reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6 [+ + +]
Author: Hersen Wu <hersenxs.wu@amd.com>
Date:   Wed Apr 24 16:00:19 2024 -0400

    drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6
    
    [ Upstream commit 84723eb6068c50610c5c0893980d230d7afa2105 ]
    
    [Why]
    Coverity reports OVERRUN warning. Should abort amdgpu_dm
    initialize.
    
    [How]
    Return failure to amdgpu_dm_init.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/pm: check negtive return for table entries [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Mon May 13 16:01:23 2024 +0800

    drm/amd/pm: check negtive return for table entries
    
    [ Upstream commit f76059fe14395b37ba8d997eb0381b1b9e80a939 ]
    
    Function hwmgr->hwmgr_func->get_num_of_pp_table_entries(hwmgr) returns a negative number
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Suggested-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: check specific index for aldebaran [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Wed May 8 17:13:28 2024 +0800

    drm/amd/pm: check specific index for aldebaran
    
    [ Upstream commit 0ce8ef2639c112ae203c985b758389e378630aac ]
    
    Check for specific indexes that may be invalid values.
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: Fix negative array index read [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Tue Apr 30 10:23:48 2024 +0800

    drm/amd/pm: Fix negative array index read
    
    [ Upstream commit c8c19ebf7c0b202a6a2d37a52ca112432723db5f ]
    
    Avoid using the negative values
    for clk_idex as an index into an array pptable->DpmDescriptor.
    
    V2: fix clk_index return check (Tim Huang)
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: fix the Out-of-bounds read warning [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Tue Apr 30 10:29:08 2024 +0800

    drm/amd/pm: fix the Out-of-bounds read warning
    
    [ Upstream commit 12c6967428a099bbba9dfd247bb4322a984fcc0b ]
    
    using index i - 1U may beyond element index
    for mc_data[] when i = 0.
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: fix uninitialized variable warning [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Sun Apr 28 15:36:26 2024 +0800

    drm/amd/pm: fix uninitialized variable warning
    
    [ Upstream commit 7c836905520703dbc8b938993b6d4d718bc739f3 ]
    
    Check the return of function smum_send_msg_to_smc
    as it may fail to initialize the variable.
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: fix uninitialized variable warning for smu8_hwmgr [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Fri Apr 26 12:52:45 2024 +0800

    drm/amd/pm: fix uninitialized variable warning for smu8_hwmgr
    
    [ Upstream commit 86df36b934640866eb249a4488abb148b985a0d9 ]
    
    Clear warnings that using uninitialized value level when fails
    to get the value from SMU.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: fix uninitialized variable warnings for vangogh_ppt [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Sun Apr 28 15:42:03 2024 +0800

    drm/amd/pm: fix uninitialized variable warnings for vangogh_ppt
    
    [ Upstream commit b2871de6961d24d421839fbfa4aa3008ec9170d5 ]
    
    1. Fix a issue that using uninitialized mask to get the ultimate frequency.
    2. Check return of smu_cmn_send_smc_msg_with_param to avoid using
    uninitialized variable residency.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: fix uninitialized variable warnings for vega10_hwmgr [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Sun Apr 28 12:41:42 2024 +0800

    drm/amd/pm: fix uninitialized variable warnings for vega10_hwmgr
    
    [ Upstream commit 5fa7d540d95d97ddc021a74583f6b3da4df9c93a ]
    
    Clear warnings that using uninitialized variable when fails
    to get the valid value from SMU.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: fix warning using uninitialized value of max_vid_step [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Mon Apr 29 15:26:25 2024 +0800

    drm/amd/pm: fix warning using uninitialized value of max_vid_step
    
    [ Upstream commit 17e3bea65cdc453695b2fe4ff26d25d17f5339e9 ]
    
    Check the return of pp_atomfwctrl_get_Voltage_table_v4
    as it may fail to initialize max_vid_step
    V2: change the check condition (Tim Huang)
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/pm: Check input value for CUSTOM profile mode setting on legacy SOCs [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Fri May 10 10:05:21 2024 +0800

    drm/amdgpu/pm: Check input value for CUSTOM profile mode setting on legacy SOCs
    
    [ Upstream commit df0a9bd92fbbd3fcafcb2bce6463c9228a3e6868 ]
    
    Check the input value for CUSTOM profile mode setting on legacy
    SOCs. Otherwise we may use uninitalized value of input[]
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu/pm: Check the return value of smum_send_msg_to_smc [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Fri Apr 26 14:38:04 2024 +0800

    drm/amdgpu/pm: Check the return value of smum_send_msg_to_smc
    
    [ Upstream commit 579f0c21baec9e7506b6bb3f60f0a9b6d07693b4 ]
    
    Check the return value of smum_send_msg_to_smc, otherwise
    we might use an uninitialized variable "now"
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu/pm: Fix uninitialized variable agc_btc_response [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Sun Apr 28 14:41:38 2024 +0800

    drm/amdgpu/pm: Fix uninitialized variable agc_btc_response
    
    [ Upstream commit df4409d8a04dd39d7f2aa0c5f528a56b99eaaa13 ]
    
    Assign an default value to agc_btc_response in failed case
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu/pm: Fix uninitialized variable warning for smu10 [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Fri Apr 26 17:46:08 2024 +0800

    drm/amdgpu/pm: Fix uninitialized variable warning for smu10
    
    [ Upstream commit 336c8f558d596699d3d9814a45600139b2f23f27 ]
    
    Check return value of smum_send_msg_to_smc to fix
    uninitialized variable varning
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: avoid reading vf2pf info size from FB [+ + +]
Author: Zhigang Luo <Zhigang.Luo@amd.com>
Date:   Tue Apr 16 16:35:14 2024 -0400

    drm/amdgpu: avoid reading vf2pf info size from FB
    
    [ Upstream commit 3bcc0ee14768d886cedff65da72d83d375a31a56 ]
    
    VF can't access FB when host is doing mode1 reset. Using sizeof to get
    vf2pf info size, instead of reading it from vf2pf header stored in FB.
    
    Signed-off-by: Zhigang Luo <Zhigang.Luo@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: fix dereference after null check [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Wed May 8 14:51:35 2024 +0800

    drm/amdgpu: fix dereference after null check
    
    [ Upstream commit b1f7810b05d1950350ac2e06992982974343e441 ]
    
    check the pointer hive before use.
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: fix mc_data out-of-bounds read warning [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Mon May 6 16:30:01 2024 +0800

    drm/amdgpu: fix mc_data out-of-bounds read warning
    
    [ Upstream commit 51dfc0a4d609fe700750a62f41447f01b8c9ea50 ]
    
    Clear warning that read mc_data[i-1] may out-of-bounds.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Tue May 7 09:29:33 2024 +0800

    drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
    
    [ Upstream commit d768394fa99467bcf2703bde74ddc96eeb0b71fa ]
    
    Check the fb_channel_number range to avoid the array out-of-bounds
    read error
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix out-of-bounds write warning [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Thu Apr 25 14:00:17 2024 +0800

    drm/amdgpu: Fix out-of-bounds write warning
    
    [ Upstream commit be1684930f5262a622d40ce7a6f1423530d87f89 ]
    
    Check the ring type value to fix the out-of-bounds
    write warning
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Suggested-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: fix overflowed array index read warning [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Thu Apr 25 13:15:27 2024 +0800

    drm/amdgpu: fix overflowed array index read warning
    
    [ Upstream commit ebbc2ada5c636a6a63d8316a3408753768f5aa9f ]
    
    Clear overflowed array index read warning by cast operation.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: fix the waring dereferencing hive [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Wed May 8 16:20:49 2024 +0800

    drm/amdgpu: fix the waring dereferencing hive
    
    [ Upstream commit 1940708ccf5aff76de4e0b399f99267c93a89193 ]
    
    Check the amdgpu_hive_info *hive that maybe is NULL.
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: fix ucode out-of-bounds read warning [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Mon May 6 16:21:00 2024 +0800

    drm/amdgpu: fix ucode out-of-bounds read warning
    
    [ Upstream commit 8944acd0f9db33e17f387fdc75d33bb473d7936f ]
    
    Clear warning that read ucode[] may out-of-bounds.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix uninitialized variable warning in amdgpu_afmt_acr [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Wed Apr 24 10:50:54 2024 +0800

    drm/amdgpu: Fix uninitialized variable warning in amdgpu_afmt_acr
    
    [ Upstream commit c0d6bd3cd209419cc46ac49562bef1db65d90e70 ]
    
    Assign value to clock to fix the warning below:
    "Using uninitialized value res. Field res.clock is uninitialized"
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: the warning dereferencing obj for nbio_v7_4 [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Mon May 13 15:22:42 2024 +0800

    drm/amdgpu: the warning dereferencing obj for nbio_v7_4
    
    [ Upstream commit d190b459b2a4304307c3468ed97477b808381011 ]
    
    if ras_manager obj null, don't print NBIO err data
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Suggested-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: update type of buf size to u32 for eeprom functions [+ + +]
Author: Tao Zhou <tao.zhou1@amd.com>
Date:   Fri May 17 18:04:26 2024 +0800

    drm/amdgpu: update type of buf size to u32 for eeprom functions
    
    [ Upstream commit 2aadb520bfacec12527effce3566f8df55e5d08e ]
    
    Avoid overflow issue.
    
    Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdkfd: Reconcile the definition and use of oem_id in struct kfd_topology_device [+ + +]
Author: Michael Chen <michael.chen@amd.com>
Date:   Fri May 3 15:31:08 2024 -0400

    drm/amdkfd: Reconcile the definition and use of oem_id in struct kfd_topology_device
    
    [ Upstream commit 10f624ef239bd136cdcc5bbc626157a57b938a31 ]
    
    Currently oem_id is defined as uint8_t[6] and casted to uint64_t*
    in some use case. This would lead code scanner to complain about
    access beyond. Re-define it in union to enforce 8-byte size and
    alignment to avoid potential issue.
    
    Signed-off-by: Michael Chen <michael.chen@amd.com>
    Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Fri May 31 22:33:12 2024 +0200

    drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ
    
    [ Upstream commit 162e48cb1d84c2c966b649b8ac5c9d4f75f6d44f ]
    
    Make sure the connector is fully initialized before signalling any
    HPD events via drm_kms_helper_hotplug_event(), otherwise this may
    lead to NULL pointer dereference.
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240531203333.277476-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/meson: plane: Add error handling [+ + +]
Author: Haoran Liu <liuhaoran14@163.com>
Date:   Wed Nov 29 03:34:05 2023 -0800

    drm/meson: plane: Add error handling
    
    [ Upstream commit 3c28b239620e249b68beeca17f429e317fa6b8d4 ]
    
    This patch adds robust error handling to the meson_plane_create
    function in drivers/gpu/drm/meson/meson_plane.c. The function
    previously lacked proper handling for potential failure scenarios
    of the drm_universal_plane_init call.
    
    Signed-off-by: Haoran Liu <liuhaoran14@163.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20231129113405.33057-1-liuhaoran14@163.com
    [narmstrong: fixe the commit subject]
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231129113405.33057-1-liuhaoran14@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: panel-orientation-quirks: Add quirk for OrangePi Neo [+ + +]
Author: Philip Mueller <philm@manjaro.org>
Date:   Mon Jul 15 11:57:49 2024 +0700

    drm: panel-orientation-quirks: Add quirk for OrangePi Neo
    
    [ Upstream commit d60c429610a14560085d98fa6f4cdb43040ca8f0 ]
    
    This adds a DMI orientation quirk for the OrangePi Neo Linux Gaming
    Handheld.
    
    Signed-off-by: Philip Mueller <philm@manjaro.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240715045818.1019979-1-philm@manjaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
ext4: fix inode tree inconsistency caused by ENOMEM [+ + +]
Author: zhanchengbin <zhanchengbin1@huawei.com>
Date:   Tue Jan 3 10:28:12 2023 +0800

    ext4: fix inode tree inconsistency caused by ENOMEM
    
    commit 3f5424790d4377839093b68c12b130077a4e4510 upstream.
    
    If ENOMEM fails when the extent is splitting, we need to restore the length
    of the split extent.
    In the ext4_split_extent_at function, only in ext4_ext_create_new_leaf will
    it alloc memory and change the shape of the extent tree,even if an ENOMEM
    is returned at this time, the extent tree is still self-consistent, Just
    restore the split extent lens in the function ext4_split_extent_at.
    
    ext4_split_extent_at
     ext4_ext_insert_extent
      ext4_ext_create_new_leaf
       1)ext4_ext_split
         ext4_find_extent
       2)ext4_ext_grow_indepth
         ext4_find_extent
    
    Signed-off-by: zhanchengbin <zhanchengbin1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20230103022812.130603-1-zhanchengbin1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: handle redirtying in ext4_bio_write_page() [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 7 12:27:04 2022 +0100

    ext4: handle redirtying in ext4_bio_write_page()
    
    commit 04e568a3b31cfbd545c04c8bfc35c20e5ccfce0f upstream.
    
    Since we want to transition transaction commits to use ext4_writepages()
    for writing back ordered, add handling of page redirtying into
    ext4_bio_write_page(). Also move buffer dirty bit clearing into the same
    place other buffer state handling.
    
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221207112722.22220-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: reject casefold inode flag without casefold feature [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Aug 14 11:29:01 2023 -0700

    ext4: reject casefold inode flag without casefold feature
    
    commit 8216776ccff6fcd40e3fdaa109aa4150ebe760b3 upstream.
    
    It is invalid for the casefold inode flag to be set without the casefold
    superblock feature flag also being set.  e2fsck already considers this
    case to be invalid and handles it by offering to clear the casefold flag
    on the inode.  __ext4_iget() also already considered this to be invalid,
    sort of, but it only got so far as logging an error message; it didn't
    actually reject the inode.  Make it reject the inode so that other code
    doesn't have to handle this case.  This matches what f2fs does.
    
    Note: we could check 's_encoding != NULL' instead of
    ext4_has_feature_casefold().  This would make the check robust against
    the casefold feature being enabled by userspace writing to the page
    cache of the mounted block device.  However, it's unsolvable in general
    for filesystems to be robust against concurrent writes to the page cache
    of the mounted block device.  Though this very particular scenario
    involving the casefold feature is solvable, we should not pretend that
    we can support this model, so let's just check the casefold feature.
    tune2fs already forbids enabling casefold on a mounted filesystem.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20230814182903.37267-2-ebiggers@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
f2fs: fix to truncate preallocated blocks in f2fs_file_open() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Wed May 29 18:01:03 2024 +0800

    f2fs: fix to truncate preallocated blocks in f2fs_file_open()
    
    commit 298b1e4182d657c3e388adcc29477904e9600ed5 upstream.
    
    chenyuwen reports a f2fs bug as below:
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000011
     fscrypt_set_bio_crypt_ctx+0x78/0x1e8
     f2fs_grab_read_bio+0x78/0x208
     f2fs_submit_page_read+0x44/0x154
     f2fs_get_read_data_page+0x288/0x5f4
     f2fs_get_lock_data_page+0x60/0x190
     truncate_partial_data_page+0x108/0x4fc
     f2fs_do_truncate_blocks+0x344/0x5f0
     f2fs_truncate_blocks+0x6c/0x134
     f2fs_truncate+0xd8/0x200
     f2fs_iget+0x20c/0x5ac
     do_garbage_collect+0x5d0/0xf6c
     f2fs_gc+0x22c/0x6a4
     f2fs_disable_checkpoint+0xc8/0x310
     f2fs_fill_super+0x14bc/0x1764
     mount_bdev+0x1b4/0x21c
     f2fs_mount+0x20/0x30
     legacy_get_tree+0x50/0xbc
     vfs_get_tree+0x5c/0x1b0
     do_new_mount+0x298/0x4cc
     path_mount+0x33c/0x5fc
     __arm64_sys_mount+0xcc/0x15c
     invoke_syscall+0x60/0x150
     el0_svc_common+0xb8/0xf8
     do_el0_svc+0x28/0xa0
     el0_svc+0x24/0x84
     el0t_64_sync_handler+0x88/0xec
    
    It is because inode.i_crypt_info is not initialized during below path:
    - mount
     - f2fs_fill_super
      - f2fs_disable_checkpoint
       - f2fs_gc
        - f2fs_iget
         - f2fs_truncate
    
    So, let's relocate truncation of preallocated blocks to f2fs_file_open(),
    after fscrypt_file_open().
    
    Fixes: d4dd19ec1ea0 ("f2fs: do not expose unwritten blocks to user by DIO")
    Reported-by: chenyuwen <yuwen.chen@xjmz.com>
    Closes: https://lore.kernel.org/linux-kernel/20240517085327.1188515-1-yuwen.chen@xjmz.com
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fsnotify: clear PARENT_WATCHED flags lazily [+ + +]
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Sun May 12 13:30:07 2024 +0200

    fsnotify: clear PARENT_WATCHED flags lazily
    
    [ Upstream commit 172e422ffea20a89bfdc672741c1aad6fbb5044e ]
    
    In some setups directories can have many (usually negative) dentries.
    Hence __fsnotify_update_child_dentry_flags() function can take a
    significant amount of time. Since the bulk of this function happens
    under inode->i_lock this causes a significant contention on the lock
    when we remove the watch from the directory as the
    __fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
    races with __fsnotify_update_child_dentry_flags() calls from
    __fsnotify_parent() happening on children. This can lead upto softlockup
    reports reported by users.
    
    Fix the problem by calling fsnotify_update_children_dentry_flags() to
    set PARENT_WATCHED flags only when parent starts watching children.
    
    When parent stops watching children, clear false positive PARENT_WATCHED
    flags lazily in __fsnotify_parent() for each accessed child.
    
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (k10temp) Check return value of amd_smn_read() [+ + +]
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date:   Thu Jun 6 11:12:56 2024 -0500

    hwmon: (k10temp) Check return value of amd_smn_read()
    
    [ Upstream commit c2d79cc5455c891de6c93e1e0c73d806e299c54f ]
    
    Check the return value of amd_smn_read() before saving a value. This
    ensures invalid values aren't saved or used.
    
    There are three cases here with slightly different behavior:
    
    1) read_tempreg_nb_zen():
            This is a function pointer which does not include a return code.
            In this case, set the register value to 0 on failure. This
            enforces Read-as-Zero behavior.
    
    2) k10temp_read_temp():
            This function does have return codes, so return the error code
            from the failed register read. Continued operation is not
            necessary, since there is no valid data from the register.
            Furthermore, if the register value was set to 0, then the
            following operation would underflow.
    
    3) k10temp_get_ccd_support():
            This function reads the same register from multiple CCD
            instances in a loop. And a bitmask is formed if a specific bit
            is set in each register instance. The loop should continue on a
            failed register read, skipping the bit check.
    
    Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20240606-fix-smn-bad-read-v4-3-ffde21931c3f@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwspinlock: Introduce hwspin_lock_bust() [+ + +]
Author: Richard Maina <quic_rmaina@quicinc.com>
Date:   Wed May 29 11:09:55 2024 -0700

    hwspinlock: Introduce hwspin_lock_bust()
    
    [ Upstream commit 7c327d56597d8de1680cf24e956b704270d3d84a ]
    
    When a remoteproc crashes or goes down unexpectedly this can result in
    a state where locks held by the remoteproc will remain locked possibly
    resulting in deadlock. This new API hwspin_lock_bust() allows
    hwspinlock implementers to define a bust operation for freeing previously
    acquired hwspinlocks after verifying ownership of the acquired lock.
    
    Signed-off-by: Richard Maina <quic_rmaina@quicinc.com>
    Reviewed-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Chris Lew <quic_clew@quicinc.com>
    Link: https://lore.kernel.org/r/20240529-hwspinlock-bust-v3-1-c8b924ffa5a2@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: Fix conditional for substituting empty ACPI functions [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Fri Aug 2 16:22:14 2024 +0100

    i2c: Fix conditional for substituting empty ACPI functions
    
    [ Upstream commit f17c06c6608ad4ecd2ccf321753fb511812d821b ]
    
    Add IS_ENABLED(CONFIG_I2C) to the conditional around a bunch of ACPI
    functions.
    
    The conditional around these functions depended only on CONFIG_ACPI.
    But the functions are implemented in I2C core, so are only present if
    CONFIG_I2C is enabled.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: Use IS_REACHABLE() for substituting empty ACPI functions [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Wed Aug 14 13:16:49 2024 +0100

    i2c: Use IS_REACHABLE() for substituting empty ACPI functions
    
    commit 71833e79a42178d8a50b5081c98c78ace9325628 upstream.
    
    Replace IS_ENABLED() with IS_REACHABLE() to substitute empty stubs for:
        i2c_acpi_get_i2c_resource()
        i2c_acpi_client_count()
        i2c_acpi_find_bus_speed()
        i2c_acpi_new_device_by_fwnode()
        i2c_adapter *i2c_acpi_find_adapter_by_handle()
        i2c_acpi_waive_d0_probe()
    
    commit f17c06c6608a ("i2c: Fix conditional for substituting empty ACPI
    functions") partially fixed this conditional to depend on CONFIG_I2C,
    but used IS_ENABLED(), which is wrong since CONFIG_I2C is tristate.
    
    CONFIG_ACPI is boolean but let's also change it to use IS_REACHABLE()
    to future-proof it against becoming tristate.
    
    Somehow despite testing various combinations of CONFIG_I2C and CONFIG_ACPI
    we missed the combination CONFIG_I2C=m, CONFIG_ACPI=y.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: f17c06c6608a ("i2c: Fix conditional for substituting empty ACPI functions")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202408141333.gYnaitcV-lkp@intel.com/
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ionic: fix potential irq name truncation [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Tue May 28 17:02:53 2024 -0700

    ionic: fix potential irq name truncation
    
    [ Upstream commit 3eb76e71b16e8ba5277bf97617aef51f5e64dbe4 ]
    
    Address a warning about potential string truncation based on the
    string buffer sizes.  We can add some hints to the string format
    specifier to set limits on the resulting possible string to
    squelch the complaints.
    
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Link: https://lore.kernel.org/r/20240529000259.25775-2-shannon.nelson@amd.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.1.109 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Sep 8 07:53:13 2024 +0200

    Linux 6.1.109
    
    Link: https://lore.kernel.org/r/20240905093716.075835938@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: uvcvideo: Enforce alignment of frame and interval [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Thu Apr 4 17:56:18 2024 +0000

    media: uvcvideo: Enforce alignment of frame and interval
    
    [ Upstream commit c8931ef55bd325052ec496f242aea7f6de47dc9c ]
    
    Struct uvc_frame and interval (u32*) are packaged together on
    streaming->formats on a single contiguous allocation.
    
    Right now they are allocated right after uvc_format, without taking into
    consideration their required alignment.
    
    This is working fine because both structures have a field with a
    pointer, but it will stop working when the sizeof() of any of those
    structs is not a multiple of the sizeof(void*).
    
    Enforce that alignment during the allocation.
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://lore.kernel.org/r/20240404-uvc-align-v2-1-9e104b0ecfbd@chromium.org
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: avoid duplicated SUB_CLOSED events [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:11:14 2024 +0200

    mptcp: avoid duplicated SUB_CLOSED events
    
    commit d82809b6c5f2676b382f77a5cbeb1a5d91ed2235 upstream.
    
    The initial subflow might have already been closed, but still in the
    connection list. When the worker is instructed to close the subflows
    that have been marked as closed, it might then try to close the initial
    subflow again.
    
     A consequence of that is that the SUB_CLOSED event can be seen twice:
    
      # ip mptcp endpoint
      1.1.1.1 id 1 subflow dev eth0
      2.2.2.2 id 2 subflow dev eth1
    
      # ip mptcp monitor &
      [         CREATED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9
      [     ESTABLISHED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9
      [  SF_ESTABLISHED] remid=0 locid=2 saddr4=2.2.2.2 daddr4=9.9.9.9
    
      # ip mptcp endpoint delete id 1
      [       SF_CLOSED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9
      [       SF_CLOSED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9
    
    The first one is coming from mptcp_pm_nl_rm_subflow_received(), and the
    second one from __mptcp_close_subflow().
    
    To avoid doing the post-closed processing twice, the subflow is now
    marked as closed the first time.
    
    Note that it is not enough to check if we are dealing with the first
    subflow and check its sk_state: the subflow might have been reset or
    closed before calling mptcp_close_ssk().
    
    Fixes: b911c97c7dc7 ("mptcp: add netlink event support")
    Cc: stable@vger.kernel.org
    Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflict in protocol.h due to commit f1f26512a9bf ("mptcp: use plain
      bool instead of custom binary enum"), commit dfc8d0603033 ("mptcp:
      implement delayed seq generation for passive fastopen") and more that
      are not in this version, because they modify the context and the size
      of __unused. The conflict is easy to resolve, by not only adding the
      new field (close_event_done), and __unused. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: make pm_remove_addrs_and_subflows static [+ + +]
Author: Geliang Tang <geliang@kernel.org>
Date:   Fri Mar 1 19:18:25 2024 +0100

    mptcp: make pm_remove_addrs_and_subflows static
    
    [ Upstream commit e38b117d7f3b4a5d810f6d0069ad0f643e503796 ]
    
    mptcp_pm_remove_addrs_and_subflows() is only used in pm_netlink.c, it's
    no longer used in pm_userspace.c any more since the commit 8b1c94da1e48
    ("mptcp: only send RM_ADDR in nl_cmd_remove"). So this patch changes it
    to a static function.
    
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 87b5896f3f78 ("mptcp: pm: fix RM_ADDR ID for the initial subflow")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mptcp: pm: avoid possible UaF when selecting endp [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 12:57:22 2024 +0200

    mptcp: pm: avoid possible UaF when selecting endp
    
    commit 48e50dcbcbaaf713d82bf2da5c16aeced94ad07d upstream.
    
    select_local_address() and select_signal_address() both select an
    endpoint entry from the list inside an RCU protected section, but return
    a reference to it, to be read later on. If the entry is dereferenced
    after the RCU unlock, reading info could cause a Use-after-Free.
    
    A simple solution is to copy the required info while inside the RCU
    protected section to avoid any risk of UaF later. The address ID might
    need to be modified later to handle the ID0 case later, so a copy seems
    OK to deal with.
    
    Reported-by: Paolo Abeni <pabeni@redhat.com>
    Closes: https://lore.kernel.org/45cd30d3-7710-491c-ae4d-a1368c00beb1@redhat.com
    Fixes: 01cacb00b35c ("mptcp: add netlink-based PM")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-14-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_netlink.c, because the context has been modified in
      commit b9d69db87fb7 ("mptcp: let the in-kernel PM use mixed IPv4 and
      IPv6 addresses"), which is not a candidate for the backports. The same
      modifications have been applied in this version. The conflict in
      mptcp_pm_create_subflow_or_signal_addr() has been resolved by taking
      the newer version, which skip a lock if it is not needed. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: fix ID 0 endp usage after multiple re-creations [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:03:09 2024 +0200

    mptcp: pm: fix ID 0 endp usage after multiple re-creations
    
    commit 9366922adc6a71378ca01f898c41be295309f044 upstream.
    
    'local_addr_used' and 'add_addr_accepted' are decremented for addresses
    not related to the initial subflow (ID0), because the source and
    destination addresses of the initial subflows are known from the
    beginning: they don't count as "additional local address being used" or
    "ADD_ADDR being accepted".
    
    It is then required not to increment them when the entrypoint used by
    the initial subflow is removed and re-added during a connection. Without
    this modification, this entrypoint cannot be removed and re-added more
    than once.
    
    Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/512
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Reported-by: syzbot+455d38ecd5f655fc45cf@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/00000000000049861306209237f4@google.com
    Cc: stable@vger.kernel.org
    Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: fix RM_ADDR ID for the initial subflow [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Aug 28 08:14:25 2024 +0200

    mptcp: pm: fix RM_ADDR ID for the initial subflow
    
    [ Upstream commit 87b5896f3f7848130095656739b05881904e2697 ]
    
    The initial subflow has a special local ID: 0. When an endpoint is being
    deleted, it is then important to check if its address is not linked to
    the initial subflow to send the right ID.
    
    If there was an endpoint linked to the initial subflow, msk's
    mpc_endpoint_id field will be set. We can then use this info when an
    endpoint is being removed to see if it is linked to the initial subflow.
    
    So now, the correct IDs are passed to mptcp_pm_nl_rm_addr_or_subflow(),
    it is no longer needed to use mptcp_local_id_match().
    
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mptcp: pm: fullmesh: select the right ID later [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 12:56:28 2024 +0200

    mptcp: pm: fullmesh: select the right ID later
    
    commit 09355f7abb9fbfc1a240be029837921ea417bf4f upstream.
    
    When reacting upon the reception of an ADD_ADDR, the in-kernel PM first
    looks for fullmesh endpoints. If there are some, it will pick them,
    using their entry ID.
    
    It should set the ID 0 when using the endpoint corresponding to the
    initial subflow, it is a special case imposed by the MPTCP specs.
    
    Note that msk->mpc_endpoint_id might not be set when receiving the first
    ADD_ADDR from the server. So better to compare the addresses.
    
    Fixes: 1a0d6136c5f0 ("mptcp: local addresses fullmesh")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-12-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_netlink.c, because the new 'mpc_addr' variable is
      added where the 'local' one was, before commit b9d69db87fb7 ("mptcp:
      let the in-kernel PM use mixed IPv4 and IPv6 addresses"), that is not
      a candidate for the backports. This 'local' variable has been moved to
      the new place to reduce the scope, and help with possible future
      backports. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: reuse ID 0 after delete and re-add [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:03:08 2024 +0200

    mptcp: pm: reuse ID 0 after delete and re-add
    
    commit 8b8ed1b429f8fa7ebd5632555e7b047bc0620075 upstream.
    
    When the endpoint used by the initial subflow is removed and re-added
    later, the PM has to force the ID 0, it is a special case imposed by the
    MPTCP specs.
    
    Note that the endpoint should then need to be re-added reusing the same
    ID.
    
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pr_debug: add missing \n at the end [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:09:27 2024 +0200

    mptcp: pr_debug: add missing \n at the end
    
    commit cb41b195e634d3f1ecfcd845314e64fd4bb3c7aa upstream.
    
    pr_debug() have been added in various places in MPTCP code to help
    developers to debug some situations. With the dynamic debug feature, it
    is easy to enable all or some of them, and asks users to reproduce
    issues with extra debug.
    
    Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
    are used in MPTCP code. So the goal was not to display multiple debug
    messages on one line: they were then not missing the '\n' on purpose.
    Not having the new line at the end causes these messages to be printed
    with a delay, when something else needs to be printed. This issue is not
    visible when many messages need to be printed, but it is annoying and
    confusing when only specific messages are expected, e.g.
    
      # echo "func mptcp_pm_add_addr_echoed +fmp" \
            > /sys/kernel/debug/dynamic_debug/control
      # ./mptcp_join.sh "signal address"; \
            echo "$(awk '{print $1}' /proc/uptime) - end"; \
            sleep 5s; \
            echo "$(awk '{print $1}' /proc/uptime) - restart"; \
            ./mptcp_join.sh "signal address"
      013 signal address
          (...)
      10.75 - end
      15.76 - restart
      013 signal address
      [  10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
          (...)
    
      => a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
         which was printed at the 15.76 ts.
    
    The 'Fixes' tag here below points to the first pr_debug() used without
    '\n' in net/mptcp. This patch could be split in many small ones, with
    different Fixes tag, but it doesn't seem worth it, because it is easy to
    re-generate this patch with this simple 'sed' command:
    
      git grep -l pr_debug -- net/mptcp |
        xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
    
    So in case of conflicts, simply drop the modifications, and launch this
    command.
    
    Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ As mentioned above, conflicts were expected, and resolved by using the
      'sed' command which is visible above. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5e: SHAMPO, Fix incorrect page release [+ + +]
Author: Dragos Tatulea <dtatulea@nvidia.com>
Date:   Tue Jun 4 00:22:07 2024 +0300

    net/mlx5e: SHAMPO, Fix incorrect page release
    
    [ Upstream commit 70bd03b89f20b9bbe51a7f73c4950565a17a45f7 ]
    
    Under the following conditions:
    1) No skb created yet
    2) header_size == 0 (no SHAMPO header)
    3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the
       last page fragment of a SHAMPO header page)
    
    a new skb is formed with a page that is NOT a SHAMPO header page (it
    is a regular data page). Further down in the same function
    (mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from
    header_index is released. This is wrong and it leads to SHAMPO header
    pages being released more than once.
    
    Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240603212219.1037656-3-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: usb: qmi_wwan: add MeiG Smart SRM825L [+ + +]
Author: ZHANG Yuntian <yt@radxa.com>
Date:   Sat Aug 3 15:46:51 2024 +0800

    net: usb: qmi_wwan: add MeiG Smart SRM825L
    
    [ Upstream commit 1ca645a2f74a4290527ae27130c8611391b07dbf ]
    
    Add support for MeiG Smart SRM825L which is based on Qualcomm 315 chip.
    
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2dee ProdID=4d22 Rev= 4.14
    S:  Manufacturer=MEIG
    S:  Product=LTE-A Module
    S:  SerialNumber=6f345e48
    C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=896mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: ZHANG Yuntian <yt@radxa.com>
    Link: https://patch.msgid.link/D1EB81385E405DFE+20240803074656.567061-1-yt@radxa.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/MSI: Fix UAF in msi_capability_init [+ + +]
Author: Mostafa Saleh <smostafa@google.com>
Date:   Mon Jun 24 20:37:28 2024 +0000

    PCI/MSI: Fix UAF in msi_capability_init
    
    commit 9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1 upstream.
    
    KFENCE reports the following UAF:
    
     BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488
    
     Use-after-free read at 0x0000000024629571 (in kfence-#12):
      __pci_enable_msi_range+0x2c0/0x488
      pci_alloc_irq_vectors_affinity+0xec/0x14c
      pci_alloc_irq_vectors+0x18/0x28
    
     kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128
    
     allocated by task 81 on cpu 7 at 10.808142s:
      __kmem_cache_alloc_node+0x1f0/0x2bc
      kmalloc_trace+0x44/0x138
      msi_alloc_desc+0x3c/0x9c
      msi_domain_insert_msi_desc+0x30/0x78
      msi_setup_msi_desc+0x13c/0x184
      __pci_enable_msi_range+0x258/0x488
      pci_alloc_irq_vectors_affinity+0xec/0x14c
      pci_alloc_irq_vectors+0x18/0x28
    
     freed by task 81 on cpu 7 at 10.811436s:
      msi_domain_free_descs+0xd4/0x10c
      msi_domain_free_locked.part.0+0xc0/0x1d8
      msi_domain_alloc_irqs_all_locked+0xb4/0xbc
      pci_msi_setup_msi_irqs+0x30/0x4c
      __pci_enable_msi_range+0x2a8/0x488
      pci_alloc_irq_vectors_affinity+0xec/0x14c
      pci_alloc_irq_vectors+0x18/0x28
    
    Descriptor allocation done in:
    __pci_enable_msi_range
        msi_capability_init
            msi_setup_msi_desc
                msi_insert_msi_desc
                    msi_domain_insert_msi_desc
                        msi_alloc_desc
                            ...
    
    Freed in case of failure in __msi_domain_alloc_locked()
    __pci_enable_msi_range
        msi_capability_init
            pci_msi_setup_msi_irqs
                msi_domain_alloc_irqs_all_locked
                    msi_domain_alloc_locked
                        __msi_domain_alloc_locked => fails
                        msi_domain_free_locked
                            ...
    
    That failure propagates back to pci_msi_setup_msi_irqs() in
    msi_capability_init() which accesses the descriptor for unmasking in the
    error exit path.
    
    Cure it by copying the descriptor and using the copy for the error exit path
    unmask operation.
    
    [ tglx: Massaged change log ]
    
    Fixes: bf6e054e0e3f ("genirq/msi: Provide msi_device_populate/destroy_sysfs()")
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Mostafa Saleh <smostafa@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Bjorn Heelgas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240624203729.1094506-1-smostafa@google.com
    Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI: al: Check IORESOURCE_BUS existence during probe [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Fri May 3 15:57:05 2024 +0300

    PCI: al: Check IORESOURCE_BUS existence during probe
    
    [ Upstream commit a9927c2cac6e9831361e43a14d91277818154e6a ]
    
    If IORESOURCE_BUS is not provided in Device Tree it will be fabricated in
    of_pci_parse_bus_range(), so NULL pointer dereference should not happen
    here.
    
    But that's hard to verify, so check for NULL anyway.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Link: https://lore.kernel.org/linux-pci/20240503125705.46055-1-amishin@t-argos.ru
    Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    [bhelgaas: commit log]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pwm: xilinx: Fix u32 overflow issue in 32-bit width PWM mode. [+ + +]
Author: Ken Sloat <ksloat@designlinxhs.com>
Date:   Thu Dec 15 16:07:15 2022 +0000

    pwm: xilinx: Fix u32 overflow issue in 32-bit width PWM mode.
    
    [ Upstream commit 56f45266df67aa0f5b2a6881c8c4d16dbfff6b7d ]
    
    This timer HW supports 8, 16 and 32-bit timer widths. This
    driver currently uses a u32 to store the max possible value
    of the timer. However, statements perform addition of 2 in
    xilinx_pwm_apply() when calculating the period_cycles and
    duty_cycles values. Since priv->max is a u32, this will
    result in an overflow to 1 which will not only be incorrect
    but fail on range comparison. This results in making it
    impossible to set the PWM in this timer mode.
    
    There are two obvious solutions to the current problem:
    1. Cast each instance where overflow occurs to u64.
    2. Change priv->max from a u32 to a u64.
    
    Solution #1 requires more code modifications, and leaves
    opportunity to introduce similar overflows if other math
    statements are added in the future. These may also go
    undetected if running in non 32-bit timer modes.
    
    Solution #2 is the much smaller and cleaner approach and
    thus the chosen method in this patch.
    
    This was tested on a Zynq UltraScale+ with multiple
    instances of the PWM IP.
    
    Signed-off-by: Ken Sloat <ksloat@designlinxhs.com>
    Reviewed-by: Michal Simek <michal.simek@amd.com>
    Reviewed-by: Sean Anderson <sean.anderson@seco.com>
    Link: https://lore.kernel.org/r/SJ0P222MB0107490C5371B848EF04351CA1E19@SJ0P222MB0107.NAMP222.PROD.OUTLOOK.COM
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rcu/nocb: Remove buggy bypass lock contention mitigation [+ + +]
Author: Frederic Weisbecker <frederic@kernel.org>
Date:   Thu Apr 25 16:18:35 2024 +0200

    rcu/nocb: Remove buggy bypass lock contention mitigation
    
    [ Upstream commit e4f78057291608f6968a6789c5ebb3bde7d95504 ]
    
    The bypass lock contention mitigation assumes there can be at most
    2 contenders on the bypass lock, following this scheme:
    
    1) One kthread takes the bypass lock
    2) Another one spins on it and increment the contended counter
    3) A third one (a bypass enqueuer) sees the contended counter on and
      busy loops waiting on it to decrement.
    
    However this assumption is wrong. There can be only one CPU to find the
    lock contended because call_rcu() (the bypass enqueuer) is the only
    bypass lock acquire site that may not already hold the NOCB lock
    beforehand, all the other sites must first contend on the NOCB lock.
    Therefore step 2) is impossible.
    
    The other problem is that the mitigation assumes that contenders all
    belong to the same rdp CPU, which is also impossible for a raw spinlock.
    In theory the warning could trigger if the enqueuer holds the bypass
    lock and another CPU flushes the bypass queue concurrently but this is
    prevented from all flush users:
    
    1) NOCB kthreads only flush if they successfully _tried_ to lock the
       bypass lock. So no contention management here.
    
    2) Flush on callbacks migration happen remotely when the CPU is offline.
       No concurrency against bypass enqueue.
    
    3) Flush on deoffloading happen either locally with IRQs disabled or
       remotely when the CPU is not yet online. No concurrency against
       bypass enqueue.
    
    4) Flush on barrier entrain happen either locally with IRQs disabled or
       remotely when the CPU is offline. No concurrency against
       bypass enqueue.
    
    For those reasons, the bypass lock contention mitigation isn't needed
    and is even wrong. Remove it but keep the warning reporting a contended
    bypass lock on a remote CPU, to keep unexpected contention awareness.
    
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/efa: Properly handle unexpected AQ completions [+ + +]
Author: Michael Margolin <mrgolin@amazon.com>
Date:   Mon May 13 06:46:30 2024 +0000

    RDMA/efa: Properly handle unexpected AQ completions
    
    [ Upstream commit 2d0e7ba468eae365f3c4bc9266679e1f8dd405f0 ]
    
    Do not try to handle admin command completion if it has an unexpected
    command id and print a relevant error message.
    
    Reviewed-by: Firas Jahjah <firasj@amazon.com>
    Reviewed-by: Yehuda Yitschak <yehuday@amazon.com>
    Signed-off-by: Michael Margolin <mrgolin@amazon.com>
    Link: https://lore.kernel.org/r/20240513064630.6247-1-mrgolin@amazon.com
    Reviewed-by: Gal Pressman <gal.pressman@linux.dev>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regmap: spi: Fix potential off-by-one when calculating reserved size [+ + +]
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Wed Jun 5 23:53:15 2024 +0300

    regmap: spi: Fix potential off-by-one when calculating reserved size
    
    [ Upstream commit d4ea1d504d2701ba04412f98dc00d45a104c52ab ]
    
    If we ever meet a hardware that uses weird register bits and padding,
    we may end up in off-by-one error since x/8 + y/8 might not be equal
    to (x + y)/8 in some cases.
    
    bits    pad   x/8+y/8 (x+y)/8
    4..7    0..3    0       0 // x + y from 4 up to 7
    4..7    4..7    0       1 // x + y from 8 up to 11
    4..7    8..11   1       1 // x + y from 12 up to 15
    8..15   0..7    1       1 // x + y from 8 up to 15
    8..15   8..15   2       2 // x + y from 16 up to 23
    
    Fix this by using (x+y)/8.
    
    Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://msgid.link/r/20240605205315.19132-1-andy.shevchenko@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: ufs: core: Bypass quick recovery if force reset is needed [+ + +]
Author: Peter Wang <peter.wang@mediatek.com>
Date:   Fri Jul 12 17:45:06 2024 +0800

    scsi: ufs: core: Bypass quick recovery if force reset is needed
    
    [ Upstream commit 022587d8aec3da1d1698ddae9fb8cfe35f3ad49c ]
    
    If force_reset is true, bypass quick recovery.  This will shorten error
    recovery time.
    
    Signed-off-by: Peter Wang <peter.wang@mediatek.com>
    Link: https://lore.kernel.org/r/20240712094506.11284-1-peter.wang@mediatek.com
    Reviewed-by: Bean Huo <beanhuo@micron.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: mptcp: add explicit test case for remove/readd [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:06:12 2024 +0200

    selftests: mptcp: add explicit test case for remove/readd
    
    From: Paolo Abeni <pabeni@redhat.com>
    
    commit b5e2fb832f48bc01d937a053e0550a1465a2f05d upstream.
    
    Delete and re-create a signal endpoint and ensure that the PM
    actually deletes and re-create the subflow.
    
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: e06959e9eebd ("selftests: mptcp: join: test for flush/re-add endpoints")
    [ No conflicts, but adapt the test to the helpers in this version:
      - run_tests has been modified a few times to reduce the number of
        positional parameters
      - no pm_nl_check_endpoint helper
      - no chk_mptcp_info helper
      - chk_subflow_nr taking an extra parameter
      - kill_tests_wait instead of mptcp_lib_kill_wait ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: cannot rm sf if closed [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:15:48 2024 +0200

    selftests: mptcp: join: cannot rm sf if closed
    
    commit e93681afcb96864ec26c3b2ce94008ce93577373 upstream.
    
    Thanks to the previous commit, the MPTCP subflows are now closed on both
    directions even when only the MPTCP path-manager of one peer asks for
    their closure.
    
    In the two tests modified here -- "userspace pm add & remove address"
    and "userspace pm create destroy subflow" -- one peer is controlled by
    the userspace PM, and the other one by the in-kernel PM. When the
    userspace PM sends a RM_ADDR notification, the in-kernel PM will
    automatically react by closing all subflows using this address. Now,
    thanks to the previous commit, the subflows are properly closed on both
    directions, the userspace PM can then no longer closes the same
    subflows if they are already closed. Before, it was OK to do that,
    because the subflows were still half-opened, still OK to send a RM_ADDR.
    
    In other words, thanks to the previous commit closing the subflows, an
    error will be returned to the userspace if it tries to close a subflow
    that has already been closed. So no need to run this command, which mean
    that the linked counters will then not be incremented.
    
    These tests are then no longer sending both a RM_ADDR, then closing the
    linked subflow just after. The test with the userspace PM on the server
    side is now removing one subflow linked to one address, then sending
    a RM_ADDR for another address. The test with the userspace PM on the
    client side is now only removing the subflow that was previously
    created.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-2-905199fe1172@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Fixes: 97040cf9806e ("selftests: mptcp: userspace pm address tests")
    Fixes: 5e986ec46874 ("selftests: mptcp: userspace pm subflow tests")
    [ It looks like this patch is needed for the same reasons as mentioned
      above, but the resolution is different: the subflows and addresses are
      removed elsewhere. The same type of adaptations have been applied
      here. The Fixes tag has been replaced by better appropriated ones. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: check re-adding init endp with != id [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:08:31 2024 +0200

    selftests: mptcp: join: check re-adding init endp with != id
    
    commit 1c2326fcae4f0c5de8ad0d734ced43a8e5f17dac upstream.
    
    The initial subflow has a special local ID: 0. It is specific per
    connection.
    
    When a global endpoint is deleted and re-added later, it can have a
    different ID, but the kernel should still use the ID 0 if it corresponds
    to the initial address.
    
    This test validates this behaviour: the endpoint linked to the initial
    subflow is removed, and re-added with a different ID.
    
    Note that removing the initial subflow will not decrement the 'subflows'
    counters, which corresponds to the *additional* subflows. On the other
    hand, when the same endpoint is re-added, it will increment this
    counter, as it will be seen as an additional subflow this time.
    
    The 'Fixes' tag here below is the same as the one from the previous
    commit: this patch here is not fixing anything wrong in the selftests,
    but it validates the previous fix for an issue introduced by this commit
    ID.
    
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflicts in mptcp_join.sh, because the helpers are different in this
      version:
      - run_tests has been modified a few times to reduce the number of
        positional parameters
      - no chk_mptcp_info helper
      - chk_subflow_nr taking an extra parameter
      - kill_tests_wait instead of mptcp_lib_kill_wait ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: check re-re-adding ID 0 endp [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:13:02 2024 +0200

    selftests: mptcp: join: check re-re-adding ID 0 endp
    
    commit d397d7246c11ca36c33c932bc36d38e3a79e9aa0 upstream.
    
    This test extends "delete and re-add" to validate the previous commit:
    when the endpoint linked to the initial subflow (ID 0) is re-added
    multiple times, it was no longer being used, because the internal linked
    counters are not decremented for this special endpoint: it is not an
    additional endpoint.
    
    Here, the "del/add id 0" steps are done 3 times to unsure this case is
    validated.
    
    The 'Fixes' tag here below is the same as the one from the previous
    commit: this patch here is not fixing anything wrong in the selftests,
    but it validates the previous fix for an issue introduced by this commit
    ID.
    
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflicts in mptcp_join.sh, because the helpers are different in this
      version:
      - run_tests has been modified a few times to reduce the number of
        positional parameters
      - no chk_mptcp_info helper
      - chk_subflow_nr taking an extra parameter
      - kill_tests_wait instead of mptcp_lib_kill_wait ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: check re-using ID of closed subflow [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:05:11 2024 +0200

    selftests: mptcp: join: check re-using ID of closed subflow
    
    commit 65fb58afa341ad68e71e5c4d816b407e6a683a66 upstream.
    
    This test extends "delete and re-add" to validate the previous commit. A
    new 'subflow' endpoint is added, but the subflow request will be
    rejected. The result is that no subflow will be established from this
    address.
    
    Later, the endpoint is removed and re-added after having cleared the
    firewall rule. Before the previous commit, the client would not have
    been able to create this new subflow.
    
    While at it, extra checks have been added to validate the expected
    numbers of MPJ and RM_ADDR.
    
    The 'Fixes' tag here below is the same as the one from the previous
    commit: this patch here is not fixing anything wrong in the selftests,
    but it validates the previous fix for an issue introduced by this commit
    ID.
    
    Fixes: b6c08380860b ("mptcp: remove addr and subflow in PM netlink")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-4-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in mptcp_join.sh, because this subtest has been modified in
      newer versions, e.g. commit 9095ce97bf8a ("selftests: mptcp: add
      mptcp_info tests") added chk_mptcp_info check, commit 03668c65d153
      ("selftests: mptcp: join: rework detailed report") changed the way
      the info are displayed, commit 04b57c9e096a ("selftests: mptcp: join:
      stop transfer when check is done (part 2)") uses the new
      mptcp_lib_kill_wait helper instead of kill_tests_wait.
      Conflicts have been resolved by not using the new helpers, the rest
      was the same. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: check re-using ID of unused ADD_ADDR [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:07:06 2024 +0200

    selftests: mptcp: join: check re-using ID of unused ADD_ADDR
    
    commit a13d5aad4dd9a309eecdc33cfd75045bd5f376a3 upstream.
    
    This test extends "delete re-add signal" to validate the previous
    commit. An extra address is announced by the server, but this address
    cannot be used by the client. The result is that no subflow will be
    established to this address.
    
    Later, the server will delete this extra endpoint, and set a new one,
    with a valid address, but re-using the same ID. Before the previous
    commit, the server would not have been able to announce this new
    address.
    
    While at it, extra checks have been added to validate the expected
    numbers of MPJ, ADD_ADDR and RM_ADDR.
    
    The 'Fixes' tag here below is the same as the one from the previous
    commit: this patch here is not fixing anything wrong in the selftests,
    but it validates the previous fix for an issue introduced by this commit
    ID.
    
    Fixes: b6c08380860b ("mptcp: remove addr and subflow in PM netlink")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-2-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in mptcp_join.sh, because the helpers are different in this
      version:
      - run_tests has been modified a few times to reduce the number of
        positional parameters
      - no chk_mptcp_info helper
      - chk_subflow_nr taking an extra parameter
      - kill_tests_wait instead of mptcp_lib_kill_wait ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: check removing ID 0 endpoint [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:12:02 2024 +0200

    selftests: mptcp: join: check removing ID 0 endpoint
    
    commit 5f94b08c001290acda94d9d8868075590931c198 upstream.
    
    Removing the endpoint linked to the initial subflow should trigger a
    RM_ADDR for the right ID, and the removal of the subflow. That's what is
    now being verified in the "delete and re-add" test.
    
    Note that removing the initial subflow will not decrement the 'subflows'
    counters, which corresponds to the *additional* subflows. On the other
    hand, when the same endpoint is re-added, it will increment this
    counter, as it will be seen as an additional subflow this time.
    
    The 'Fixes' tag here below is the same as the one from the previous
    commit: this patch here is not fixing anything wrong in the selftests,
    but it validates the previous fix for an issue introduced by this commit
    ID.
    
    Fixes: 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflicts in mptcp_join.sh, because the helpers are different in this
      version:
      - run_tests has been modified a few times to reduce the number of
        positional parameters
      - no chk_mptcp_info helper
      - chk_subflow_nr taking an extra parameter
      - kill_tests_wait instead of mptcp_lib_kill_wait ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: no extra msg if no counter [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:12:34 2024 +0200

    selftests: mptcp: join: no extra msg if no counter
    
    commit 76a2d8394cc183df872adf04bf636eaf42746449 upstream.
    
    The checksum and fail counters might not be available. Then no need to
    display an extra message with missing info.
    
    While at it, fix the indentation around, which is wrong since the same
    commit.
    
    Fixes: 47867f0a7e83 ("selftests: mptcp: join: skip check if MIB counter not supported")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflicts in mptcp_join.sh, because the context is different, but the
      exact same fix can still be applied on the modified lines: adding
      '[ -n "$count" ]', and fixing the indentation. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: test for flush/re-add endpoints [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:06:13 2024 +0200

    selftests: mptcp: join: test for flush/re-add endpoints
    
    commit e06959e9eebdfea4654390f53b65cff57691872e upstream.
    
    After having flushed endpoints that didn't cause the creation of new
    subflows, it is important to check endpoints can be re-created, re-using
    previously used IDs.
    
    Before the previous commit, the client would not have been able to
    re-create the subflow that was previously rejected.
    
    The 'Fixes' tag here below is the same as the one from the previous
    commit: this patch here is not fixing anything wrong in the selftests,
    but it validates the previous fix for an issue introduced by this commit
    ID.
    
    Fixes: 06faa2271034 ("mptcp: remove multi addresses and subflows in PM")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-6-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ No conflicts, but adapt the test to the helpers in this version:
      - run_tests has been modified a few times to reduce the number of
        positional parameters
      - no chk_mptcp_info helper
      - chk_subflow_nr taking an extra parameter
      - kill_tests_wait instead of mptcp_lib_kill_wait ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: mptcp: join: validate fullmesh endp on 1st sf [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Sep 4 13:04:31 2024 +0200

    selftests: mptcp: join: validate fullmesh endp on 1st sf
    
    commit 4878f9f8421f4587bee7b232c1c8a9d3a7d4d782 upstream.
    
    This case was not covered, and the wrong ID was set before the previous
    commit.
    
    The rest is not modified, it is just that it will increase the code
    coverage.
    
    The right address ID can be verified by looking at the packet traces. We
    could automate that using Netfilter with some cBPF code for example, but
    that's always a bit cryptic. Packetdrill seems better fitted for that.
    
    Fixes: 4f49d63352da ("selftests: mptcp: add fullmesh testcases")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-13-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in mptcp_join.sh, because the 'run_tests' helper has been
      modified in multiple commits that are not in this version, e.g. commit
      e571fb09c893 ("selftests: mptcp: add speed env var"). The conflict was
      in the context, the new line can still be added at the same place. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smack: tcp: ipv4, fix incorrect labeling [+ + +]
Author: Casey Schaufler <casey@schaufler-ca.com>
Date:   Wed Jun 5 15:41:50 2024 -0700

    smack: tcp: ipv4, fix incorrect labeling
    
    [ Upstream commit 2fe209d0ad2e2729f7e22b9b31a86cc3ff0db550 ]
    
    Currently, Smack mirrors the label of incoming tcp/ipv4 connections:
    when a label 'foo' connects to a label 'bar' with tcp/ipv4,
    'foo' always gets 'foo' in returned ipv4 packets. So,
    1) returned packets are incorrectly labeled ('foo' instead of 'bar')
    2) 'bar' can write to 'foo' without being authorized to write.
    
    Here is a scenario how to see this:
    
    * Take two machines, let's call them C and S,
       with active Smack in the default state
       (no settings, no rules, no labeled hosts, only builtin labels)
    
    * At S, add Smack rule 'foo bar w'
       (labels 'foo' and 'bar' are instantiated at S at this moment)
    
    * At S, at label 'bar', launch a program
       that listens for incoming tcp/ipv4 connections
    
    * From C, at label 'foo', connect to the listener at S.
       (label 'foo' is instantiated at C at this moment)
       Connection succeedes and works.
    
    * Send some data in both directions.
    * Collect network traffic of this connection.
    
    All packets in both directions are labeled with the CIPSO
    of the label 'foo'. Hence, label 'bar' writes to 'foo' without
    being authorized, and even without ever being known at C.
    
    If anybody cares: exactly the same happens with DCCP.
    
    This behavior 1st manifested in release 2.6.29.4 (see Fixes below)
    and it looks unintentional. At least, no explanation was provided.
    
    I changed returned packes label into the 'bar',
    to bring it into line with the Smack documentation claims.
    
    Signed-off-by: Konstantin Andreev <andreev@swemel.ru>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udf: Limit file size to 4TB [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jan 25 17:56:06 2023 +0100

    udf: Limit file size to 4TB
    
    commit c2efd13a2ed4f29bf9ef14ac2fbb7474084655f8 upstream.
    
    UDF disk format supports in principle file sizes up to 1<<64-1. However
    the file space (including holes) is described by a linked list of
    extents, each of which can have at most 1GB. Thus the creation and
    handling of extents gets unusably slow beyond certain point. Limit the
    file size to 4TB to avoid locking up the kernel too easily.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: typec: ucsi: Fix null pointer dereference in trace [+ + +]
Author: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Date:   Fri May 10 20:12:41 2024 +0000

    usb: typec: ucsi: Fix null pointer dereference in trace
    
    [ Upstream commit 99516f76db48e1a9d54cdfed63c1babcee4e71a5 ]
    
    ucsi_register_altmode checks IS_ERR for the alt pointer and treats
    NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,
    ucsi_register_displayport returns NULL which causes a NULL pointer
    dereference in trace. Rather than return NULL, call
    typec_port_register_altmode to register DisplayPort alternate mode
    as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.
    
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
    Signed-off-by: Jameson Thies <jthies@google.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240510201244.2968152-2-jthies@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usbip: Don't submit special requests twice [+ + +]
Author: Simon Holesch <simon@holesch.de>
Date:   Sun May 19 16:15:38 2024 +0200

    usbip: Don't submit special requests twice
    
    [ Upstream commit 8b6b386f9aa936ed0c190446c71cf59d4a507690 ]
    
    Skip submitting URBs, when identical requests were already sent in
    tweak_special_requests(). Instead call the completion handler directly
    to return the result of the URB.
    
    Even though submitting those requests twice should be harmless, there
    are USB devices that react poorly to some duplicated requests.
    
    One example is the ChipIdea controller implementation in U-Boot: The
    second SET_CONFIGURATION request makes U-Boot disable and re-enable all
    endpoints. Re-enabling an endpoint in the ChipIdea controller, however,
    was broken until U-Boot commit b272c8792502 ("usb: ci: Fix gadget
    reinit").
    
    Signed-off-by: Simon Holesch <simon@holesch.de>
    Acked-by: Shuah Khan <skhan@linuxfoundation.org>
    Reviewed-by: Hongren Zheng <i@zenithal.me>
    Tested-by: Hongren Zheng <i@zenithal.me>
    Link: https://lore.kernel.org/r/20240519141922.171460-1-simon@holesch.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio_net: Fix napi_skb_cache_put warning [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Fri Jul 12 04:53:25 2024 -0700

    virtio_net: Fix napi_skb_cache_put warning
    
    commit f8321fa75102246d7415a6af441872f6637c93ab upstream.
    
    After the commit bdacf3e34945 ("net: Use nested-BH locking for
    napi_alloc_cache.") was merged, the following warning began to appear:
    
             WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0
    
              __warn+0x12f/0x340
              napi_skb_cache_put+0x82/0x4b0
              napi_skb_cache_put+0x82/0x4b0
              report_bug+0x165/0x370
              handle_bug+0x3d/0x80
              exc_invalid_op+0x1a/0x50
              asm_exc_invalid_op+0x1a/0x20
              __free_old_xmit+0x1c8/0x510
              napi_skb_cache_put+0x82/0x4b0
              __free_old_xmit+0x1c8/0x510
              __free_old_xmit+0x1c8/0x510
              __pfx___free_old_xmit+0x10/0x10
    
    The issue arises because virtio is assuming it's running in NAPI context
    even when it's not, such as in the netpoll case.
    
    To resolve this, modify virtnet_poll_tx() to only set NAPI when budget
    is available. Same for virtnet_poll_cleantx(), which always assumed that
    it was in a NAPI context.
    
    Fixes: df133f3f9625 ("virtio_net: bulk free tx skbs")
    Suggested-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: Jakub Kicinski <kuba@kernel.org>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Heng Qi <hengqi@linux.alibaba.com>
    Link: https://patch.msgid.link/20240712115325.54175-1-leitao@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [Shivani: Modified to apply on v6.6.y]
    Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: ath11k: initialize 'ret' in ath11k_qmi_load_file_target_mem() [+ + +]
Author: Jeff Johnson <quic_jjohnson@quicinc.com>
Date:   Sat May 4 11:52:09 2024 -0700

    wifi: ath11k: initialize 'ret' in ath11k_qmi_load_file_target_mem()
    
    [ Upstream commit 199f149e97dc7be80e5eed4b232529c1d1aa8055 ]
    
    smatch flagged the following issue:
    
    drivers/net/wireless/ath/ath11k/qmi.c:2401 ath11k_qmi_load_file_target_mem() error: uninitialized symbol 'ret'.
    
    The reality is that 'ret' is initialized in every path through
    ath11k_qmi_load_file_target_mem() except one, the case where the input
    'len' is 0, and hence the "while (remaining)" loop is never entered.
    But to make sure this case is also handled, add an initializer to the
    declaration of 'ret'.
    
    No functional changes, compile tested only.
    
    Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://msgid.link/20240504-qmi_load_file_target_mem-v1-2-069fc44c45eb@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: make hash table duplicates more survivable [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jun 7 20:17:17 2024 +0200

    wifi: cfg80211: make hash table duplicates more survivable
    
    [ Upstream commit 7f12e26a194d0043441f870708093d9c2c3bad7d ]
    
    Jiazi Li reported that they occasionally see hash table duplicates
    as evidenced by the WARN_ON() in rb_insert_bss() in this code.  It
    isn't clear how that happens, nor have I been able to reproduce it,
    but if it does happen, the kernel crashes later, when it tries to
    unhash the entry that's now not hashed.
    
    Try to make this situation more survivable by removing the BSS from
    the list(s) as well, that way it's fully leaked here (as had been
    the intent in the hash insert error path), and no longer reachable
    through the list(s) so it shouldn't be unhashed again later.
    
    Link: https://lore.kernel.org/r/20231026013528.GA24122@Jiazi.Li
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Link: https://msgid.link/20240607181726.36835-2-johannes@sipsolutions.net
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: remove fw_running op [+ + +]
Author: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Date:   Fri May 10 17:06:40 2024 +0300

    wifi: iwlwifi: remove fw_running op
    
    [ Upstream commit 37733bffda3285d18bd1d72c14b3a1cf39c56a5e ]
    
    fw_running assumes that memory can be retrieved only after alive.
    This assumption is no longer true as we support dump before alive.
    To avoid invalid access to the NIC, check that STATUS_DEVICE_ENABLED
    bit in trans status is set before dumping instead of the prior check.
    
    Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
    Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240510170500.ca07138cedeb.I090e31d3eaeb4ba19f5f84aba997ccd36927e9ac@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtw89: ser: avoid multiple deinit on same CAM [+ + +]
Author: Zong-Zhe Yang <kevin_yang@realtek.com>
Date:   Thu May 9 17:06:43 2024 +0800

    wifi: rtw89: ser: avoid multiple deinit on same CAM
    
    [ Upstream commit cea4066588308fa932b6b03486c608efff1d761c ]
    
    We did deinit CAM in STA iteration in VIF loop. But, the STA iteration
    missed to restrict the target VIF. So, if there are multiple VIFs, we
    would deinit a CAM multiple times. Now, fix it.
    
    Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://msgid.link/20240509090646.35304-2-pkshih@realtek.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>