Linux 6.8.11

 
admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Tue Apr 23 12:34:25 2024 +0200

    admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET
    
    commit 8af2d1ab78f2342f8c4c3740ca02d86f0ebfac5a upstream.
    
    sched_core_share_pid() copies the cookie to userspace with
    put_user(id, (u64 __user *)uaddr), expecting 64 bits of space.
    The "unsigned long" datatype that is documented in core-scheduling.rst
    however is only 32 bits large on 32 bit architectures.
    
    Document "unsigned long long" as the correct data type that is always
    64bits large.
    
    This matches what the selftest cs_prctl_test.c has been doing all along.
    
    Fixes: 0159bb020ca9 ("Documentation: Add usecases, design and interface for core scheduling")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/util-linux/df7a25a0-7923-4f8b-a527-5e6f0064074d@t-8ch.de/
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Reviewed-by: Chris Hyser <chris.hyser@oracle.com>
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Link: https://lore.kernel.org/r/20240423-core-scheduling-cookie-v1-1-5753a35f8dfc@weissschuh.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
binder: fix max_thread type inconsistency [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Sun Apr 21 17:37:49 2024 +0000

    binder: fix max_thread type inconsistency
    
    commit 42316941335644a98335f209daafa4c122f28983 upstream.
    
    The type defined for the BINDER_SET_MAX_THREADS ioctl was changed from
    size_t to __u32 in order to avoid incompatibility issues between 32 and
    64-bit kernels. However, the internal types used to copy from user and
    store the value were never updated. Use u32 to fix the inconsistency.
    
    Fixes: a9350fc859ae ("staging: android: binder: fix BINDER_SET_MAX_THREADS declaration")
    Reported-by: Arve Hjønnevåg <arve@android.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Link: https://lore.kernel.org/r/20240421173750.3117808-1-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
block: add a disk_has_partscan helper [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu May 2 15:00:32 2024 +0200

    block: add a disk_has_partscan helper
    
    commit 140ce28dd3bee8e53acc27f123ae474d69ef66f0 upstream.
    
    Add a helper to check if partition scanning is enabled instead of
    open coding the check in a few places.  This now always checks for
    the hidden flag even if all but one of the callers are never reachable
    for hidden gendisks.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20240502130033.1958492-2-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

block: add a partscan sysfs attribute for disks [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu May 2 15:00:33 2024 +0200

    block: add a partscan sysfs attribute for disks
    
    commit a4217c6740dc64a3eb6815868a9260825e8c68c6 upstream.
    
    Userspace had been unknowingly relying on a non-stable interface of
    kernel internals to determine if partition scanning is enabled for a
    given disk. Provide a stable interface for this purpose instead.
    
    Cc: stable@vger.kernel.org # 6.3+
    Depends-on: 140ce28dd3be ("block: add a disk_has_partscan helper")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/linux-block/ZhQJf8mzq_wipkBH@gardel-login/
    Link: https://lore.kernel.org/r/20240502130033.1958492-3-hch@lst.de
    [axboe: add links and commit message from Keith]
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init() [+ + +]
Author: Sungwoo Kim <iam@sung-woo.kim>
Date:   Sat May 4 15:23:29 2024 -0400

    Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
    
    commit a5b862c6a221459d54e494e88965b48dcfa6cc44 upstream.
    
    l2cap_le_flowctl_init() can cause both div-by-zero and an integer
    overflow since hdev->le_mtu may not fall in the valid range.
    
    Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
    process earlier if MTU is invalid.
    Also, add a missing validation in read_buffer_size() and make it return
    an error value if the validation fails.
    Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
    kzalloc failure and invalid MTU value.
    
    divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
    CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    Workqueue: hci0 hci_rx_work
    RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
    Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
    89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d
    b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
    RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
    RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
    RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
    RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
    R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
    R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
    FS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
     l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
     l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
     l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
     l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
     hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
     hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
     process_one_work kernel/workqueue.c:3254 [inline]
     process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
     worker_thread+0x926/0xe70 kernel/workqueue.c:3416
     kthread+0x2e3/0x380 kernel/kthread.c:388
     ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
     </TASK>
    Modules linked in:
    ---[ end trace 0000000000000000 ]---
    
    Fixes: 6ed58ec520ad ("Bluetooth: Use LE buffers for LE traffic")
    Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
    Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect() [+ + +]
Author: Sungwoo Kim <iam@sung-woo.kim>
Date:   Tue Apr 30 02:32:10 2024 -0400

    Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
    
    commit 4d7b41c0e43995b0e992b9f8903109275744b658 upstream.
    
    Extend a critical section to prevent chan from early freeing.
    Also make the l2cap_connect() return type void. Nothing is using the
    returned value but it is ugly to return a potentially freed pointer.
    Making it void will help with backports because earlier kernels did use
    the return value. Now the compile will break for kernels where this
    patch is not a complete fix.
    
    Call stack summary:
    
    [use]
    l2cap_bredr_sig_cmd
      l2cap_connect
      ┌ mutex_lock(&conn->chan_lock);
      │ chan = pchan->ops->new_connection(pchan); <- alloc chan
      │ __l2cap_chan_add(conn, chan);
      │   l2cap_chan_hold(chan);
      │   list_add(&chan->list, &conn->chan_l);   ... (1)
      └ mutex_unlock(&conn->chan_lock);
        chan->conf_state              ... (4) <- use after free
    
    [free]
    l2cap_conn_del
    ┌ mutex_lock(&conn->chan_lock);
    │ foreach chan in conn->chan_l:            ... (2)
    │   l2cap_chan_put(chan);
    │     l2cap_chan_destroy
    │       kfree(chan)               ... (3) <- chan freed
    └ mutex_unlock(&conn->chan_lock);
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in instrument_atomic_read
    include/linux/instrumented.h:68 [inline]
    BUG: KASAN: slab-use-after-free in _test_bit
    include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
    BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0
    net/bluetooth/l2cap_core.c:4260
    Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311
    
    Fixes: 73ffa904b782 ("Bluetooth: Move conf_{req,rsp} stuff to struct l2cap_chan")
    Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Docs/admin-guide/mm/damon/usage: fix wrong example of DAMOS filter matching sysfs file [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Fri May 3 11:03:14 2024 -0700

    Docs/admin-guide/mm/damon/usage: fix wrong example of DAMOS filter matching sysfs file
    
    commit da2a061888883e067e8e649d086df35c92c760a7 upstream.
    
    The example usage of DAMOS filter sysfs files, specifically the part of
    'matching' file writing for memcg type filter, is wrong.  The intention is
    to exclude pages of a memcg that already getting enough care from a given
    scheme, but the example is setting the filter to apply the scheme to only
    the pages of the memcg.  Fix it.
    
    Link: https://lkml.kernel.org/r/20240503180318.72798-7-sj@kernel.org
    Fixes: 9b7f9322a530 ("Docs/admin-guide/mm/damon/usage: document DAMOS filters of sysfs")
    Closes: https://lore.kernel.org/r/20240317191358.97578-1-sj@kernel.org
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>    [6.3.x]
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
docs: kernel_include.py: Cope with docutils 0.21 [+ + +]
Author: Akira Yokosawa <akiyks@gmail.com>
Date:   Wed May 1 12:16:11 2024 +0900

    docs: kernel_include.py: Cope with docutils 0.21
    
    commit d43ddd5c91802a46354fa4c4381416ef760676e2 upstream.
    
    Running "make htmldocs" on a newly installed Sphinx 7.3.7 ends up in
    a build error:
    
        Sphinx parallel build error:
        AttributeError: module 'docutils.nodes' has no attribute 'reprunicode'
    
    docutils 0.21 has removed nodes.reprunicode, quote from release note [1]:
    
      * Removed objects:
    
        docutils.nodes.reprunicode, docutils.nodes.ensure_str()
            Python 2 compatibility hacks
    
    Sphinx 7.3.0 supports docutils 0.21 [2]:
    
    kernel_include.py, whose origin is misc.py of docutils, uses reprunicode.
    
    Upstream docutils removed the offending line from the corresponding file
    (docutils/docutils/parsers/rst/directives/misc.py) in January 2022.
    Quoting the changelog [3]:
    
        Deprecate `nodes.reprunicode` and `nodes.ensure_str()`.
    
        Drop uses of the deprecated constructs (not required with Python 3).
    
    Do the same for kernel_include.py.
    
    Tested against:
      - Sphinx 2.4.5 (docutils 0.17.1)
      - Sphinx 3.4.3 (docutils 0.17.1)
      - Sphinx 5.3.0 (docutils 0.18.1)
      - Sphinx 6.2.1 (docutils 0.19)
      - Sphinx 7.2.6 (docutils 0.20.1)
      - Sphinx 7.3.7 (docutils 0.21.2)
    
    Link: http://www.docutils.org/RELEASE-NOTES.html#release-0-21-2024-04-09 [1]
    Link: https://www.sphinx-doc.org/en/master/changes.html#release-7-3-0-released-apr-16-2024 [2]
    Link: https://github.com/docutils/docutils/commit/c8471ce47a24 [3]
    Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Link: https://lore.kernel.org/r/faf5fa45-2a9d-4573-9d2e-3930bdc1ed65@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Fix division by zero in setup_dsc_config [+ + +]
Author: Jose Fernandez <josef@netflix.com>
Date:   Mon Apr 22 08:35:44 2024 -0600

    drm/amd/display: Fix division by zero in setup_dsc_config
    
    commit 130afc8a886183a94cf6eab7d24f300014ff87ba upstream.
    
    When slice_height is 0, the division by slice_height in the calculation
    of the number of slices will cause a division by zero driver crash. This
    leaves the kernel in a state that requires a reboot. This patch adds a
    check to avoid the division by zero.
    
    The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on
    a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor
    connected via Thunderbolt. The amdgpu driver crashed with this exception
    when I rebooted the system with the monitor connected.
    
    kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)
    kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)
    kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
    kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)
    kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
    kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))
    kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
    kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)
    kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
    kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu
    
    After applying this patch, the driver no longer crashes when the monitor
    is connected and the system is rebooted. I believe this is the same
    issue reported for 3113.
    
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Jose Fernandez <josef@netflix.com>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3113
    Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <mario.limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
erofs: get rid of erofs_fs_context [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Apr 19 20:36:10 2024 +0800

    erofs: get rid of erofs_fs_context
    
    commit 07abe43a28b2c660f726d66f5470f7f114f9643a upstream.
    
    Instead of allocating the erofs_sb_info in fill_super() allocate it during
    erofs_init_fs_context() and ensure that erofs can always have the info
    available during erofs_kill_sb(). After this erofs_fs_context is no longer
    needed, replace ctx with sbi, no functional changes.
    
    Suggested-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Link: https://lore.kernel.org/r/20240419123611.947084-2-libaokun1@huawei.com
    [ Gao Xiang: trivial conflict due to a warning message. ]
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

erofs: reliably distinguish block based and fscache mode [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Fri Apr 19 20:36:11 2024 +0800

    erofs: reliably distinguish block based and fscache mode
    
    commit 7af2ae1b1531feab5d38ec9c8f472dc6cceb4606 upstream.
    
    When erofs_kill_sb() is called in block dev based mode, s_bdev may not
    have been initialised yet, and if CONFIG_EROFS_FS_ONDEMAND is enabled,
    it will be mistaken for fscache mode, and then attempt to free an anon_dev
    that has never been allocated, triggering the following warning:
    
    ============================================
    ida_free called for id=0 which is not allocated.
    WARNING: CPU: 14 PID: 926 at lib/idr.c:525 ida_free+0x134/0x140
    Modules linked in:
    CPU: 14 PID: 926 Comm: mount Not tainted 6.9.0-rc3-dirty #630
    RIP: 0010:ida_free+0x134/0x140
    Call Trace:
     <TASK>
     erofs_kill_sb+0x81/0x90
     deactivate_locked_super+0x35/0x80
     get_tree_bdev+0x136/0x1e0
     vfs_get_tree+0x2c/0xf0
     do_new_mount+0x190/0x2f0
     [...]
    ============================================
    
    Now when erofs_kill_sb() is called, erofs_sb_info must have been
    initialised, so use sbi->fsid to distinguish between the two modes.
    
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Link: https://lore.kernel.org/r/20240419123611.947084-3-libaokun1@huawei.com
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ice: pass VSI pointer into ice_vc_isvalid_q_id [+ + +]
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Fri Feb 16 14:06:35 2024 -0800

    ice: pass VSI pointer into ice_vc_isvalid_q_id
    
    commit a21605993dd5dfd15edfa7f06705ede17b519026 upstream.
    
    The ice_vc_isvalid_q_id() function takes a VSI index and a queue ID. It
    looks up the VSI from its index, and then validates that the queue number
    is valid for that VSI.
    
    The VSI ID passed is typically a VSI index from the VF. This VSI number is
    validated by the PF to ensure that it matches the VSI associated with the
    VF already.
    
    In every flow where ice_vc_isvalid_q_id() is called, the PF driver already
    has a pointer to the VSI associated with the VF. This pointer is obtained
    using ice_get_vf_vsi(), rather than looking up the VSI using the index sent
    by the VF.
    
    Since we already know which VSI to operate on, we can modify
    ice_vc_isvalid_q_id() to take a VSI pointer instead of a VSI index. Pass
    the VSI we found from ice_get_vf_vsi() instead of re-doing the lookup. This
    removes some unnecessary computation and scanning of the VSI list.
    
    It also removes the last place where the driver directly used the VSI
    number from the VF. This will pave the way for refactoring to communicate
    relative VSI numbers to the VF instead of absolute numbers from the PF
    space.
    
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ice: remove unnecessary duplicate checks for VF VSI ID [+ + +]
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Fri Feb 16 14:06:36 2024 -0800

    ice: remove unnecessary duplicate checks for VF VSI ID
    
    commit 363f689600dd010703ce6391bcfc729a97d21840 upstream.
    
    The ice_vc_fdir_param_check() function validates that the VSI ID of the
    virtchnl flow director command matches the VSI number of the VF. This is
    already checked by the call to ice_vc_isvalid_vsi_id() immediately
    following this.
    
    This check is unnecessary since ice_vc_isvalid_vsi_id() already confirms
    this by checking that the VSI ID can locate the VSI associated with the VF
    structure.
    
    Furthermore, a following change is going to refactor the ice driver to
    report VSI IDs using a relative index for each VF instead of reporting the
    PF VSI number. This additional check would break that logic since it
    enforces that the VSI ID matches the VSI number.
    
    Since this check duplicates  the logic in ice_vc_isvalid_vsi_id() and gets
    in the way of refactoring that logic, remove it.
    
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KEYS: trusted: Do not use WARN when encode fails [+ + +]
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Mon May 13 21:19:04 2024 +0300

    KEYS: trusted: Do not use WARN when encode fails
    
    commit 050bf3c793a07f96bd1e2fd62e1447f731ed733b upstream.
    
    When asn1_encode_sequence() fails, WARN is not the correct solution.
    
    1. asn1_encode_sequence() is not an internal function (located
       in lib/asn1_encode.c).
    2. Location is known, which makes the stack trace useless.
    3. Results a crash if panic_on_warn is set.
    
    It is also noteworthy that the use of WARN is undocumented, and it
    should be avoided unless there is a carefully considered rationale to
    use it.
    
    Replace WARN with pr_err, and print the return value instead, which is
    only useful piece of information.
    
    Cc: stable@vger.kernel.org # v5.13+
    Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs")
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KEYS: trusted: Fix memory leak in tpm2_key_encode() [+ + +]
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Mon May 20 02:31:53 2024 +0300

    KEYS: trusted: Fix memory leak in tpm2_key_encode()
    
    commit ffcaa2172cc1a85ddb8b783de96d38ca8855e248 upstream.
    
    'scratch' is never freed. Fix this by calling kfree() in the success, and
    in the error case.
    
    Cc: stable@vger.kernel.org # +v5.13
    Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs")
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.8.11 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat May 25 16:28:41 2024 +0200

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

 
net: ks8851: Fix another TX stall caused by wrong ISR flag handling [+ + +]
Author: Ronald Wahl <ronald.wahl@raritan.com>
Date:   Mon May 13 16:39:22 2024 +0200

    net: ks8851: Fix another TX stall caused by wrong ISR flag handling
    
    commit 317a215d493230da361028ea8a4675de334bfa1a upstream.
    
    Under some circumstances it may happen that the ks8851 Ethernet driver
    stops sending data.
    
    Currently the interrupt handler resets the interrupt status flags in the
    hardware after handling TX. With this approach we may lose interrupts in
    the time window between handling the TX interrupt and resetting the TX
    interrupt status bit.
    
    When all of the three following conditions are true then transmitting
    data stops:
    
      - TX queue is stopped to wait for room in the hardware TX buffer
      - no queued SKBs in the driver (txq) that wait for being written to hw
      - hardware TX buffer is empty and the last TX interrupt was lost
    
    This is because reenabling the TX queue happens when handling the TX
    interrupt status but if the TX status bit has already been cleared then
    this interrupt will never come.
    
    With this commit the interrupt status flags will be cleared before they
    are handled. That way we stop losing interrupts.
    
    The wrong handling of the ISR flags was there from the beginning but
    with commit 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX
    buffer overrun") the issue becomes apparent.
    
    Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun")
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Simon Horman <horms@kernel.org>
    Cc: netdev@vger.kernel.org
    Cc: stable@vger.kernel.org # 5.10+
    Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: ax88179_178a: fix link status when link is set to down/up [+ + +]
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Fri May 10 11:08:28 2024 +0200

    net: usb: ax88179_178a: fix link status when link is set to down/up
    
    commit ecf848eb934b03959918f5269f64c0e52bc23998 upstream.
    
    The idea was to keep only one reset at initialization stage in order to
    reduce the total delay, or the reset from usbnet_probe or the reset from
    usbnet_open.
    
    I have seen that restarting from usbnet_probe is necessary to avoid doing
    too complex things. But when the link is set to down/up (for example to
    configure a different mac address) the link is not correctly recovered
    unless a reset is commanded from usbnet_open.
    
    So, detect the initialization stage (first call) to not reset from
    usbnet_open after the reset from usbnet_probe and after this stage, always
    reset from usbnet_open too (when the link needs to be rechecked).
    
    Apply to all the possible devices, the behavior now is going to be the same.
    
    cc: stable@vger.kernel.org # 6.6+
    Fixes: 56f78615bcb1 ("net: usb: ax88179_178a: avoid writing the mac address before first reading")
    Reported-by: Isaac Ganoung <inventor500@vivaldi.net>
    Reported-by: Yongqin Liu <yongqin.liu@linaro.org>
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240510090846.328201-1-jtornosm@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
remoteproc: mediatek: Make sure IPI buffer fits in L2TCM [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Mar 21 09:46:13 2024 +0100

    remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
    
    commit 331f91d86f71d0bb89a44217cc0b2a22810bbd42 upstream.
    
    The IPI buffer location is read from the firmware that we load to the
    System Companion Processor, and it's not granted that both the SRAM
    (L2TCM) size that is defined in the devicetree node is large enough
    for that, and while this is especially true for multi-core SCP, it's
    still useful to check on single-core variants as well.
    
    Failing to perform this check may make this driver perform R/W
    operations out of the L2TCM boundary, resulting (at best) in a
    kernel panic.
    
    To fix that, check that the IPI buffer fits, otherwise return a
    failure and refuse to boot the relevant SCP core (or the SCP at
    all, if this is single core).
    
    Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240321084614.45253-2-angelogioacchino.delregno@collabora.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
serial: kgdboc: Fix NMI-safety problems from keyboard reset code [+ + +]
Author: Daniel Thompson <daniel.thompson@linaro.org>
Date:   Wed Apr 24 15:21:41 2024 +0100

    serial: kgdboc: Fix NMI-safety problems from keyboard reset code
    
    commit b2aba15ad6f908d1a620fd97f6af5620c3639742 upstream.
    
    Currently, when kdb is compiled with keyboard support, then we will use
    schedule_work() to provoke reset of the keyboard status.  Unfortunately
    schedule_work() gets called from the kgdboc post-debug-exception
    handler.  That risks deadlock since schedule_work() is not NMI-safe and,
    even on platforms where the NMI is not directly used for debugging, the
    debug trap can have NMI-like behaviour depending on where breakpoints
    are placed.
    
    Fix this by using the irq work system, which is NMI-safe, to defer the
    call to schedule_work() to a point when it is safe to call.
    
    Reported-by: Liuye <liu.yeC@h3c.com>
    Closes: https://lore.kernel.org/all/20240228025602.3087748-1-liu.yeC@h3c.com/
    Cc: stable@vger.kernel.org
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20240424-kgdboc_fix_schedule_work-v2-1-50f5a490aec5@linaro.org
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc3: Wait unconditionally after issuing EndXfer command [+ + +]
Author: Prashanth K <quic_prashk@quicinc.com>
Date:   Thu May 2 10:11:03 2024 +0530

    usb: dwc3: Wait unconditionally after issuing EndXfer command
    
    commit 1d26ba0944d398f88aaf997bda3544646cf21945 upstream.
    
    Currently all controller IP/revisions except DWC3_usb3 >= 310a
    wait 1ms unconditionally for ENDXFER completion when IOC is not
    set. This is because DWC_usb3 controller revisions >= 3.10a
    supports GUCTL2[14: Rst_actbitlater] bit which allows polling
    CMDACT bit to know whether ENDXFER command is completed.
    
    Consider a case where an IN request was queued, and parallelly
    soft_disconnect was called (due to ffs_epfile_release). This
    eventually calls stop_active_transfer with IOC cleared, hence
    send_gadget_ep_cmd() skips waiting for CMDACT cleared during
    EndXfer. For DWC3 controllers with revisions >= 310a, we don't
    forcefully wait for 1ms either, and we proceed by unmapping the
    requests. If ENDXFER didn't complete by this time, it leads to
    SMMU faults since the controller would still be accessing those
    requests.
    
    Fix this by ensuring ENDXFER completion by adding 1ms delay in
    __dwc3_stop_active_transfer() unconditionally.
    
    Cc: stable@vger.kernel.org
    Fixes: b353eb6dc285 ("usb: dwc3: gadget: Skip waiting for CMDACT cleared during endxfer")
    Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240502044103.1066350-1-quic_prashk@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: tipd: fix event checking for tps25750 [+ + +]
Author: Javier Carrasco <javier.carrasco@wolfvision.net>
Date:   Mon Apr 29 15:35:57 2024 +0200

    usb: typec: tipd: fix event checking for tps25750
    
    commit d64adb0f41e62f91fcfdf0e0d9d5bfa714db0d23 upstream.
    
    In its current form, the interrupt service routine of the tps25750
    checks the event flags in the lowest 64 bits of the interrupt event
    register (event[0]), but also in the upper part (event[1]).
    
    Given that all flags are defined as BIT() or BIT_ULL(), they are
    restricted to the first 64 bits of the INT_EVENT1 register. Including
    the upper part of the register can lead to false positives e.g. if the
    event 64 bits above the one being checked is set, but the one being
    checked is not.
    
    Restrict the flag checking to the first 64 bits of the INT_EVENT1
    register.
    
    Fixes: 7e7a3c815d22 ("USB: typec: tps6598x: Add TPS25750 support")
    Cc: stable@vger.kernel.org
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
    Link: https://lore.kernel.org/r/20240429-tps6598x_fix_event_handling-v3-1-4e8e58dce489@wolfvision.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: tipd: fix event checking for tps6598x [+ + +]
Author: Javier Carrasco <javier.carrasco@wolfvision.net>
Date:   Mon Apr 29 15:35:58 2024 +0200

    usb: typec: tipd: fix event checking for tps6598x
    
    commit 409c1cfb5a803f3cf2d17aeaf75c25c4be951b07 upstream.
    
    The current interrupt service routine of the tps6598x only reads the
    first 64 bits of the INT_EVENT1 and INT_EVENT2 registers, which means
    that any event above that range will be ignored, leaving interrupts
    unattended. Moreover, those events will not be cleared, and the device
    will keep the interrupt enabled.
    
    This issue has been observed while attempting to load patches, and the
    'ReadyForPatch' field (bit 81) of INT_EVENT1 was set.
    
    Given that older versions of the tps6598x (1, 2 and 6) provide 8-byte
    registers, a mechanism based on the upper byte of the version register
    (0x0F) has been included. The manufacturer has confirmed [1] that this
    byte is always 0 for older versions, and either 0xF7 (DH parts) or 0xF9
    (DK parts) is returned in newer versions (7 and 8).
    
    Read the complete INT_EVENT registers to handle all interrupts generated
    by the device and account for the hardware version to select the
    register size.
    
    Link: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1346521/tps65987d-register-command-to-distinguish-between-tps6591-2-6-and-tps65987-8 [1]
    Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
    Cc: stable@vger.kernel.org
    Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
    Link: https://lore.kernel.org/r/20240429-tps6598x_fix_event_handling-v3-2-4e8e58dce489@wolfvision.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: ucsi: displayport: Fix potential deadlock [+ + +]
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Tue May 7 16:43:16 2024 +0300

    usb: typec: ucsi: displayport: Fix potential deadlock
    
    commit b791a67f68121d69108640d4a3e591d210ffe850 upstream.
    
    The function ucsi_displayport_work() does not access the
    connector, so it also must not acquire the connector lock.
    
    This fixes a potential deadlock scenario:
    
    ucsi_displayport_work() -> lock(&con->lock)
    typec_altmode_vdm()
    dp_altmode_vdm()
    dp_altmode_work()
    typec_altmode_enter()
    ucsi_displayport_enter() -> lock(&con->lock)
    
    Reported-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode")
    Cc: stable@vger.kernel.org
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240507134316.161999-1-heikki.krogerus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>