Linux 5.15.160

 
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>

 
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>
 
drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Tue Dec 26 15:32:19 2023 +0530

    drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper()
    
    commit b8d55a90fd55b767c25687747e2b24abd1ef8680 upstream.
    
    Return invalid error code -EINVAL for invalid block id.
    
    Fixes the below:
    
    drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed 'info' could be null (see line 1176)
    
    Suggested-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Cc: Tao Zhou <tao.zhou1@amd.com>
    Cc: Hawking Zhang <Hawking.Zhang@amd.com>
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    [Ajay: applied AMDGPU_RAS_BLOCK_COUNT condition to amdgpu_ras_query_error_status()
           as amdgpu_ras_query_error_status_helper() not present in v5.15
           amdgpu_ras_query_error_status_helper() was introduced in 8cc0f5669eb6]
    Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.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>

 
KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Mar 22 07:32:59 2023 -0700

    KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection
    
    commit 6c41468c7c12d74843bb414fc00307ea8a6318c3 upstream.
    
    When injecting an exception into a vCPU in Real Mode, suppress the error
    code by clearing the flag that tracks whether the error code is valid, not
    by clearing the error code itself.  The "typo" was introduced by recent
    fix for SVM's funky Paged Real Mode.
    
    Opportunistically hoist the logic above the tracepoint so that the trace
    is coherent with respect to what is actually injected (this was also the
    behavior prior to the buggy commit).
    
    Fixes: b97f07458373 ("KVM: x86: determine if an exception has an error code only when injecting it.")
    Cc: stable@vger.kernel.org
    Cc: Maxim Levitsky <mlevitsk@redhat.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20230322143300.2209476-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [nsaenz: backport to 5.15.y]
    Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Acked-by: Sean Christopherson <seanjc@google.com>

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

    Linux 5.15.160
    
    Link: https://lore.kernel.org/r/20240523130327.956341021@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: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL access [+ + +]
Author: Doug Berger <opendmb@gmail.com>
Date:   Thu Apr 25 15:27:19 2024 -0700

    net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL access
    
    commit d85cf67a339685beae1d0aee27b7f61da95455be upstream.
    
    The EXT_RGMII_OOB_CTRL register can be written from different
    contexts. It is predominantly written from the adjust_link
    handler which is synchronized by the phydev->lock, but can
    also be written from a different context when configuring the
    mii in bcmgenet_mii_config().
    
    The chances of contention are quite low, but it is conceivable
    that adjust_link could occur during resume when WoL is enabled
    so use the phydev->lock synchronizer in bcmgenet_mii_config()
    to be sure.
    
    Fixes: afe3f907d20f ("net: bcmgenet: power on MII block for all MII modes")
    Cc: stable@vger.kernel.org
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: bcmgenet: synchronize UMAC_CMD access [+ + +]
Author: Doug Berger <opendmb@gmail.com>
Date:   Thu Apr 25 15:27:21 2024 -0700

    net: bcmgenet: synchronize UMAC_CMD access
    
    commit 0d5e2a82232605b337972fb2c7d0cbc46898aca1 upstream.
    
    The UMAC_CMD register is written from different execution
    contexts and has insufficient synchronization protections to
    prevent possible corruption. Of particular concern are the
    acceses from the phy_device delayed work context used by the
    adjust_link call and the BH context that may be used by the
    ndo_set_rx_mode call.
    
    A spinlock is added to the driver to protect contended register
    accesses (i.e. reg_lock) and it is used to synchronize accesses
    to UMAC_CMD.
    
    Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
    Cc: stable@vger.kernel.org
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: tls: factor out tls_*crypt_async_wait() [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Feb 6 17:18:18 2024 -0800

    net: tls: factor out tls_*crypt_async_wait()
    
    commit c57ca512f3b68ddcd62bda9cc24a8f5584ab01b1 upstream.
    
    Factor out waiting for async encrypt and decrypt to finish.
    There are already multiple copies and a subsequent fix will
    need more. No functional changes.
    
    Note that crypto_wait_req() returns wait->err
    
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: aec7961916f3 ("tls: fix race between async notify and socket close")
    [v5.15: removed changes in tls_sw_splice_eof and adjusted waiting factor out for
    async descrypt in tls_sw_recvmsg]
    Cc: <stable@vger.kernel.org> # 5.15
    Signed-off-by: Shaoying Xu <shaoyi@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: tls: handle backlogging of crypto requests [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Feb 6 17:18:21 2024 -0800

    net: tls: handle backlogging of crypto requests
    
    commit 8590541473188741055d27b955db0777569438e3 upstream.
    
    Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our
    requests to the crypto API, crypto_aead_{encrypt,decrypt} can return
     -EBUSY instead of -EINPROGRESS in valid situations. For example, when
    the cryptd queue for AESNI is full (easy to trigger with an
    artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued
    to the backlog but still processed. In that case, the async callback
    will also be called twice: first with err == -EINPROGRESS, which it
    seems we can just ignore, then with err == 0.
    
    Compared to Sabrina's original patch this version uses the new
    tls_*crypt_async_wait() helpers and converts the EBUSY to
    EINPROGRESS to avoid having to modify all the error handling
    paths. The handling is identical.
    
    Fixes: a54667f6728c ("tls: Add support for encryption using async offload accelerator")
    Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls records")
    Co-developed-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/netdev/9681d1febfec295449a62300938ed2ae66983f28.1694018970.git.sd@queasysnail.net/
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [v5.15: fixed contextual merge-conflicts in tls_decrypt_done and tls_encrypt_done]
    Cc: <stable@vger.kernel.org> # 5.15
    Signed-off-by: Shaoying Xu <shaoyi@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netlink: annotate data-races around sk->sk_err [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Oct 3 18:34:55 2023 +0000

    netlink: annotate data-races around sk->sk_err
    
    commit d0f95894fda7d4f895b29c1097f92d7fee278cb2 upstream.
    
    syzbot caught another data-race in netlink when
    setting sk->sk_err.
    
    Annotate all of them for good measure.
    
    BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg
    
    write to 0xffff8881613bb220 of 4 bytes by task 28147 on cpu 0:
    netlink_recvmsg+0x448/0x780 net/netlink/af_netlink.c:1994
    sock_recvmsg_nosec net/socket.c:1027 [inline]
    sock_recvmsg net/socket.c:1049 [inline]
    __sys_recvfrom+0x1f4/0x2e0 net/socket.c:2229
    __do_sys_recvfrom net/socket.c:2247 [inline]
    __se_sys_recvfrom net/socket.c:2243 [inline]
    __x64_sys_recvfrom+0x78/0x90 net/socket.c:2243
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    write to 0xffff8881613bb220 of 4 bytes by task 28146 on cpu 1:
    netlink_recvmsg+0x448/0x780 net/netlink/af_netlink.c:1994
    sock_recvmsg_nosec net/socket.c:1027 [inline]
    sock_recvmsg net/socket.c:1049 [inline]
    __sys_recvfrom+0x1f4/0x2e0 net/socket.c:2229
    __do_sys_recvfrom net/socket.c:2247 [inline]
    __se_sys_recvfrom net/socket.c:2243 [inline]
    __x64_sys_recvfrom+0x78/0x90 net/socket.c:2243
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x00000000 -> 0x00000016
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 28146 Comm: syz-executor.0 Not tainted 6.6.0-rc3-syzkaller-00055-g9ed22ae6be81 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20231003183455.3410550-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: yenchia.chen <yenchia.chen@mediatek.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netlink: annotate lockless accesses to nlk->max_recvmsg_len [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Apr 3 21:46:43 2023 +0000

    netlink: annotate lockless accesses to nlk->max_recvmsg_len
    
    commit a1865f2e7d10dde00d35a2122b38d2e469ae67ed upstream.
    
    syzbot reported a data-race in data-race in netlink_recvmsg() [1]
    
    Indeed, netlink_recvmsg() can be run concurrently,
    and netlink_dump() also needs protection.
    
    [1]
    BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg
    
    read to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0:
    netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988
    sock_recvmsg_nosec net/socket.c:1017 [inline]
    sock_recvmsg net/socket.c:1038 [inline]
    __sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194
    __do_sys_recvfrom net/socket.c:2212 [inline]
    __se_sys_recvfrom net/socket.c:2208 [inline]
    __x64_sys_recvfrom+0x78/0x90 net/socket.c:2208
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    write to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1:
    netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989
    sock_recvmsg_nosec net/socket.c:1017 [inline]
    sock_recvmsg net/socket.c:1038 [inline]
    ____sys_recvmsg+0x156/0x310 net/socket.c:2720
    ___sys_recvmsg net/socket.c:2762 [inline]
    do_recvmmsg+0x2e5/0x710 net/socket.c:2856
    __sys_recvmmsg net/socket.c:2935 [inline]
    __do_sys_recvmmsg net/socket.c:2958 [inline]
    __se_sys_recvmmsg net/socket.c:2951 [inline]
    __x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x0000000000000000 -> 0x0000000000001000
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
    
    Fixes: 9063e21fb026 ("netlink: autosize skb lengthes")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20230403214643.768555-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: yenchia.chen <yenchia.chen@mediatek.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfsd: don't allow nfsd threads to be signalled. [+ + +]
Author: NeilBrown <neilb@suse.de>
Date:   Tue Jul 18 16:38:08 2023 +1000

    nfsd: don't allow nfsd threads to be signalled.
    
    commit 3903902401451b1cd9d797a8c79769eb26ac7fe5 upstream.
    
    The original implementation of nfsd used signals to stop threads during
    shutdown.
    In Linux 2.3.46pre5 nfsd gained the ability to shutdown threads
    internally it if was asked to run "0" threads.  After this user-space
    transitioned to using "rpc.nfsd 0" to stop nfsd and sending signals to
    threads was no longer an important part of the API.
    
    In commit 3ebdbe5203a8 ("SUNRPC: discard svo_setup and rename
    svc_set_num_threads_sync()") (v5.17-rc1~75^2~41) we finally removed the
    use of signals for stopping threads, using kthread_stop() instead.
    
    This patch makes the "obvious" next step and removes the ability to
    signal nfsd threads - or any svc threads.  nfsd stops allowing signals
    and we don't check for their delivery any more.
    
    This will allow for some simplification in later patches.
    
    A change worth noting is in nfsd4_ssc_setup_dul().  There was previously
    a signal_pending() check which would only succeed when the thread was
    being shut down.  It should really have tested kthread_should_stop() as
    well.  Now it just does the latter, not the former.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin() [+ + +]
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Wed Jul 19 23:22:52 2023 +0300

    pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin()
    
    commit ecfe9a015d3e1e46504d5b3de7eef1f2d186194a upstream.
    
    pinctrl_register_one_pin() doesn't check the result of radix_tree_insert()
    despite they both may return a negative error code.  Linus Walleij said he
    has copied the radix tree code from kernel/irq/ where the functions calling
    radix_tree_insert() are *void* themselves; I think it makes more sense to
    propagate the errors from radix_tree_insert() upstream if we can do that...
    
    Found by Linux Verification Center (linuxtesting.org) with the Svace static
    analysis tool.
    
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/20230719202253.13469-3-s.shtylyov@omp.ru
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: "Hemdan, Hagar Gamal Halim" <hagarhem@amazon.de>
    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>

 
Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems" [+ + +]
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Mon May 6 01:46:35 2024 -0700

    Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems"
    
    This reverts commit 0d29b474fb90ff35920642f378d9baace9b47edd which is
    commit 91b80cc5b39f00399e8e2d17527cad2c7fa535e2 upstream.
    
    map_hugetlb.c:18:10: fatal error: vm_util.h: No such file or directory
       18 | #include "vm_util.h"
          |          ^~~~~~~~~~~
    compilation terminated.
    
    vm_util.h is not present in 5.15.y, as commit:642bc52aed9c ("selftests:
    vm: bring common functions to a new file") is not present in stable
    kernels <=6.1.y
    
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>

 
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>

 
tls: extract context alloc/initialization out of tls_set_sw_offload [+ + +]
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Mon Oct 9 22:50:46 2023 +0200

    tls: extract context alloc/initialization out of tls_set_sw_offload
    
    commit 615580cbc99af0da2d1c7226fab43a3d5003eb97 upstream.
    
    Simplify tls_set_sw_offload a bit.
    
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: aec7961916f3 ("tls: fix race between async notify and socket close")
    [v5.15: fixed contextual conflicts from unavailable init_waitqueue_head and
    skb_queue_head_init calls in tls_set_sw_offload and init_ctx_rx]
    Cc: <stable@vger.kernel.org> # 5.15
    Signed-off-by: Shaoying Xu <shaoyi@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tls: fix race between async notify and socket close [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Feb 6 17:18:19 2024 -0800

    tls: fix race between async notify and socket close
    
    commit aec7961916f3f9e88766e2688992da6980f11b8d upstream.
    
    The submitting thread (one which called recvmsg/sendmsg)
    may exit as soon as the async crypto handler calls complete()
    so any code past that point risks touching already freed data.
    
    Try to avoid the locking and extra flags altogether.
    Have the main thread hold an extra reference, this way
    we can depend solely on the atomic ref counter for
    synchronization.
    
    Don't futz with reiniting the completion, either, we are now
    tightly controlling when completion fires.
    
    Reported-by: valis <sec@valis.email>
    Fixes: 0cada33241d9 ("net/tls: fix race condition causing kernel panic")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [v5.15: fixed contextual conflicts in struct tls_sw_context_rx and func
    init_ctx_rx; replaced DEBUG_NET_WARN_ON_ONCE with BUILD_BUG_ON_INVALID
    since they're equivalent when DEBUG_NET is not defined]
    Cc: <stable@vger.kernel.org> # 5.15
    Signed-off-by: Shaoying Xu <shaoyi@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tls: rx: simplify async wait [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Fri Apr 8 11:31:27 2022 -0700

    tls: rx: simplify async wait
    
    commit 37943f047bfb88ba4dfc7a522563f57c86d088a0 upstream.
    
    Since we are protected from async completions by decrypt_compl_lock
    we can drop the async_notify and reinit the completion before we
    start waiting.
    
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: aec7961916f3 ("tls: fix race between async notify and socket close")
    Signed-off-by: Shaoying Xu <shaoyi@amazon.com>
    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>