deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2020-1819
Published: 2024-12-27
Description: There are multiple out of bounds (OOB) read vulnerabilities in the implementation of the Common Open Policy Service (COPS) protocol of some Huawei products. The specific decoding function may occur out-of-bounds read when processes an incoming data packet. Successful exploit of these vulnerabilities may disrupt service on the affected device. (Vulnerability ID: HWPSIRT-2018-12275,HWPSIRT-2018-12276,HWPSIRT-2018-12277,HWPSIRT-2018-12278,HWPSIRT-2018-12279,HWPSIRT-2018-12280 and HWPSIRT-2018-12289)

The seven vulnerabilities have been assigned seven Common Vulnerabilities and Exposures (CVE) IDs: CVE-2020-1818, CVE-2020-1819, CVE-2020-1820, CVE-2020-1821, CVE-2020-1822, CVE-2020-1823 and CVE-2020-1824.
CVSS Score: 3.7 (LOW)
CWE: CWE-125, CWE-125
References: https://www.huawei.com/en/psirt/security-advisories/2020/huawei-sa-20191218-01-cops-en
CVE: CVE-2020-9080
Published: 2024-12-27
Description: There is an improper privilege management vulnerability in Huawei smart phone product. A local, authenticated attacker could craft a specific input to exploit this vulnerability. Successful exploitation may lead to local privilege escalation. (Vulnerability ID: HWPSIRT-2020-05272)

This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9080.
CVSS Score: 7.8 (HIGH)
CWE: CWE-269
References: https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200819-01-smartphone-en
CVE: CVE-2020-9081
Published: 2024-12-27
Description: There is an improper authorization vulnerability in some Huawei smartphones. An attacker could perform a series of operation in specific mode to exploit this vulnerability. Successful exploit could allow the attacker to bypass app lock. (Vulnerability ID: HWPSIRT-2019-12144)



This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9081.
CVSS Score: 3.5 (LOW)
CWE: CWE-285, CWE-863
References: https://www.huawei.com/en/psirt/security-advisories/2020/huawei-sa-20200826-15-smartphone-en
CVE: CVE-2020-9082
Published: 2024-12-27
Description: There is an information disclosure vulnerability in several smartphones. The system has a logic judging error under certain scenario, the attacker should gain the permit to execute commands in ADB mode and then do a series of operation on the phone. Successful exploit could allow the attacker to gain certain information from certain apps locked by Applock. (Vulnerability ID: HWPSIRT-2019-07112)

This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9082.
CVSS Score: 3.5 (LOW)
CWE: CWE-200
References: https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200826-16-smartphone-en
CVE: CVE-2020-9085
Published: 2024-12-27
Description: There is a NULL pointer dereference vulnerability in some Huawei products. An attacker may send specially crafted POST messages to the affected products. Due to insufficient validation of some parameter in the message, successful exploit may cause some process abnormal. (Vulnerability ID: HWPSIRT-2017-10105)

This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9085.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200826-01-pointer_en
CVE: CVE-2020-9086
Published: 2024-12-27
Description: There is a buffer error vulnerability in some Huawei product. An unauthenticated attacker may send special UPNP message to the affected products. Due to insufficient input validation of some value, successful exploit may cause some service abnormal. (Vulnerability ID: HWPSIRT-2017-08234)

This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9086.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-124, CWE-787
References: https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200826-01-buffer_en
CVE: CVE-2020-9089
Published: 2024-12-27
Description: There is an information vulnerability in Huawei smartphones. A function in a module can be called without verifying the caller's access. Attackers with user access can exploit this vulnerability to obtain some information. This can lead to information leak. (Vulnerability ID: HWPSIRT-2019-12141)

This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9089.
CVSS Score: 3.3 (LOW)
CWE: CWE-200
References: https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200826-09-smartphone-en
CVE: CVE-2020-9210
Published: 2024-12-27
Description: There is an insufficient integrity vulnerability in Huawei products. A module does not perform sufficient integrity check in a specific scenario. Attackers can exploit the vulnerability by physically install malware. This could compromise normal service of the affected device. (Vulnerability ID: HWPSIRT-2020-00145)

This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9210.
CVSS Score: 6.8 (MEDIUM)
CWE: CWE-354, CWE-354
References: https://www.huawei.com/en/psirt/security-advisories/2021/huawei-sa-20210106-01-myna-en
CVE: CVE-2020-9211
Published: 2024-12-27
Description: There is an out-of-bound read and write vulnerability in Huawei smartphone. A module dose not verify the input sufficiently. Attackers can exploit this vulnerability by modifying some configuration to cause out-of-bound read and write, causing denial of service. (Vulnerability ID: HWPSIRT-2020-05103)

This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9211.
CVSS Score: 6.4 (MEDIUM)
CWE: CWE-125, CWE-125, CWE-787
References: https://www.huawei.com/en/psirt/security-advisories/2021/huawei-sa-20210106-01-smartphone-en
CVE: CVE-2020-9222
Published: 2024-12-27
Description: There is a privilege escalation vulnerability in Huawei FusionCompute product. Due to insufficient verification on specific files that need to be deserialized, local attackers can exploit this vulnerability to elevate permissions. (Vulnerability ID: HWPSIRT-2020-05241)

This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9222.
CVSS Score: 7.0 (HIGH)
CWE: CWE-269
References: https://www.huawei.com/en/psirt/security-advisories/2020/huawei-sa-20200826-01-fc-en
CVE: CVE-2020-9236
Published: 2024-12-27
Description: There is an improper interface design vulnerability in Huawei product. A module interface of the impated product does not deal with some operations properly. Attackers can exploit this vulnerability to perform malicious operatation to compromise module service. (Vulnerability ID: HWPSIRT-2020-05010)


This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9236.
CVSS Score: 8.8 (HIGH)
CWE: CWE-451
References: https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200812-01-fc-en
CVE: CVE-2020-9253
Published: 2024-12-27
Description: There is a stack overflow vulnerability in some Huawei smart phone. An attacker can craft specific packet to exploit this vulnerability. Due to insufficient verification, this could be exploited to tamper with the information to affect the availability. (Vulnerability ID: HWPSIRT-2019-11030)

This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9253.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-121, CWE-787
References: https://www.huawei.com/en/psirt/security-advisories/2020/huawei-sa-20200715-08-smartphone-en
CVE: CVE-2024-3393
Published: 2024-12-27
Description: A Denial of Service vulnerability in the DNS Security feature of Palo Alto Networks PAN-OS software allows an unauthenticated attacker to send a malicious packet through the data plane of the firewall that reboots the firewall. Repeated attempts to trigger this condition will cause the firewall to enter maintenance mode.
CVSS Score: 7.5 (HIGH)
CWE: CWE-754, CWE-754
References: https://security.paloaltonetworks.com/CVE-2024-3393; https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-3393
CVE: CVE-2022-49034
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK

When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected,
cpu_max_bits_warn() generates a runtime warning similar as below when
showing /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)
instead of NR_CPUS to iterate CPUs.

[    3.052463] ------------[ cut here ]------------
[    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
[    3.070072] Modules linked in: efivarfs autofs4
[    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
[    3.099465] Stack :[PII_REDACTED]157b08[PII_REDACTED]f18[PII_REDACTED]000cf846c [PII_REDACTED]
[    3.109127]        [PII_REDACTED]157a50 [PII_REDACTED][PII_REDACTED]157a58[PII_REDACTED]ef7430
[    3.118774]        [PII_REDACTED]1578e8 [PII_REDACTED] [PII_REDACTED] ffffffffffffffff
[    3.128412]        [PII_REDACTED]aaaaaa 1ab25f00eec96a37[PII_REDACTED]21de80[PII_REDACTED]01c890
[    3.138056]         [PII_REDACTED] [PII_REDACTED] [PII_REDACTED][PII_REDACTED]aaaaaa
[    3.147711]         ffff8000339dc220 [PII_REDACTED][PII_REDACTED]ab4000 [PII_REDACTED]
[    3.157364]        [PII_REDACTED]01c998 [PII_REDACTED][PII_REDACTED]ef7430 [PII_REDACTED]
[    3.167012]         [PII_REDACTED][PII_REDACTED]00006c [PII_REDACTED] [PII_REDACTED]
[    3.176641]        [PII_REDACTED]d3de08 [PII_REDACTED][PII_REDACTED]2086d8 00007ffff0080286
[    3.186260]        [PII_REDACTED]0000b0 [PII_REDACTED] [PII_REDACTED][PII_REDACTED]071c1c
[    3.195868]         ...
[    3.199917] Call Trace:
[    3.203941] [<[PII_REDACTED]2086d8>] show_stack+0x38/0x14c
[    3.210666] [<[PII_REDACTED]cf846c>] dump_stack_lvl+0x60/0x88
[    3.217625] [<[PII_REDACTED]23d268>] __warn+0xd0/0x100
[    3.223958] [<[PII_REDACTED]cf3c90>] warn_slowpath_fmt+0x7c/0xcc
[    3.231150] [<[PII_REDACTED]>] show_cpuinfo+0x5e8/0x5f0
[    3.238080] [<[PII_REDACTED]4f578c>] seq_read_iter+0x354/0x4b4
[    3.245098] [<[PII_REDACTED]4c2e90>] new_sync_read+0x17c/0x1c4
[    3.252114] [<[PII_REDACTED]4c5174>] vfs_read+0x138/0x1d0
[    3.258694] [<[PII_REDACTED]4c55f8>] ksys_read+0x70/0x100
[    3.265265] [<[PII_REDACTED]cfde9c>] do_syscall+0x7c/0x94
[    3.271820] [<[PII_REDACTED]202fe4>] handle_syscall+0xc4/0x160
[    3.281824] ---[ end trace 8b484262b4b8c24c ]---
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/09faf32c682ea4a547200b8b9e04d8b3c8e84b55; https://git.kernel.org/stable/c/2b6b8e011fab680a223b5e07a3c64774156ec6fe; https://git.kernel.org/stable/c/39373f6f89f52770a5405d30dddd08a27d097872
CVE: CVE-2024-53164
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: sched: fix ordering of qlen adjustment

Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen
_before_ a call to said function because otherwise it may fail to notify
parent qdiscs when the child is about to become empty.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/33db36b3c53d0fda2699ea39ba72bee4de8336e8; https://git.kernel.org/stable/c/44782565e1e6174c94bddfa72ac7267cd09c1648; https://git.kernel.org/stable/c/489422e2befff88a1de52b2acebe7b333bded025
CVE: CVE-2024-53165
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

sh: intc: Fix use-after-free bug in register_intc_controller()

In the error handling for this function, d is freed without ever
removing it from intc_list which would lead to a use after free.
To fix this, let's only add it to the list after everything has
succeeded.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/3c7c806b3eafd94ae0f77305a174d63b69ec187c; https://git.kernel.org/stable/c/588bdec1ff8b81517dbae0ae51c9df52c0b952d3; https://git.kernel.org/stable/c/63e72e551942642c48456a[PII_REDACTED]cdcb9b3c
CVE: CVE-2024-53167
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

nfs/blocklayout: Don't attempt unregister for invalid block device

Since commit d869da91cccb ("nfs/blocklayout: Fix premature PR key
unregistration") an unmount of a pNFS SCSI layout-enabled NFS may
dereference a NULL block_device in:

  bl_unregister_scsi+0x16/0xe0 [blocklayoutdriver]
  bl_free_device+0x70/0x80 [blocklayoutdriver]
  bl_free_deviceid_node+0x12/0x30 [blocklayoutdriver]
  nfs4_put_deviceid_node+0x60/0xc0 [nfsv4]
  nfs4_deviceid_purge_client+0x132/0x190 [nfsv4]
  unset_pnfs_layoutdriver+0x59/0x60 [nfsv4]
  nfs4_destroy_server+0x36/0x70 [nfsv4]
  nfs_free_server+0x23/0xe0 [nfs]
  deactivate_locked_super+0x30/0xb0
  cleanup_mnt+0xba/0x150
  task_work_run+0x59/0x90
  syscall_exit_to_user_mode+0x217/0x220
  do_syscall_64+0x8e/0x160

This happens because even though we were able to create the
nfs4_deviceid_node, the lookup for the device was unable to attach the
block device to the pnfs_block_dev.

If we never found a block device to register, we can avoid this case with
the PNFS_BDEV_REGISTERED flag.  Move the deref behind the test for the
flag.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3402704a424f34bbcca7f4a[PII_REDACTED]f422217; https://git.kernel.org/stable/c/3a4ce14d9a6b868e0787e4582420b721c04ee41e; https://git.kernel.org/stable/c/faa4bacfaeed827a4ca8cb8529a3ce65a9e8ef46
CVE: CVE-2024-53172
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ubi: fastmap: Fix duplicate slab cache names while attaching

Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when
DEBUG_VM=y"), the duplicate slab cache names can be detected and a
kernel WARNING is thrown out.
In UBI fast attaching process, alloc_ai() could be invoked twice
with the same slab cache name 'ubi_aeb_slab_cache', which will trigger
following warning messages:
 kmem_cache of name 'ubi_aeb_slab_cache' already exists
 WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107
          __kmem_cache_create_args+0x100/0x5f0
 Modules linked in: ubi(+) nandsim [last unloaded: nandsim]
 CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2
 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0
 Call Trace:
   __kmem_cache_create_args+0x100/0x5f0
   alloc_ai+0x295/0x3f0 [ubi]
   ubi_attach+0x3c3/0xcc0 [ubi]
   ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi]
   ubi_init+0x3fb/0x800 [ubi]
   do_init_module+0x265/0x7d0
   __x64_sys_finit_module+0x7a/0xc0

The problem could be easily reproduced by loading UBI device by fastmap
with CONFIG_DEBUG_VM=y.
Fix it by using different slab names for alloc_ai() callers.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04c0b0f[PII_REDACTED]9c34e207c5550d081f585a6; https://git.kernel.org/stable/c/3d8558135cd56a2a8052024be4073e160f36658c; https://git.kernel.org/stable/c/612824dd0c9465ef365ace38b056c663d110956d
CVE: CVE-2024-53173
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSv4.0: Fix a use-after-free problem in the asynchronous open()

Yang Erkun reports that when two threads are opening files at the same
time, and are forced to abort before a reply is seen, then the call to
nfs_release_seqid() in nfs4_opendata_free() can result in a
use-after-free of the pointer to the defunct rpc task of the other
thread.
The fix is to ensure that if the RPC call is aborted before the call to
nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid()
in nfs4_open_release() before the rpc_task is freed.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/1cfae9575296f5040cdc84b0730e79078c081d2d; https://git.kernel.org/stable/c/229a30ed42bb87bcb044c5523fabd9e4f0e75648; https://git.kernel.org/stable/c/2ab9639f16b05d948066a6c4cf19a0fdc61046ff
CVE: CVE-2024-53174
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: make sure cache entry active before cache_show

The function `c_show` was called with protection from RCU. This only
ensures that `cp` will not be freed. Therefore, the reference count for
`cp` can drop to zero, which will trigger a refcount use-after-free
warning when `cache_get` is called. To resolve this issue, use
`cache_get_rcu` to ensure that `cp` remains active.

------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 7 PID: 822 at lib/refcount.c:25
refcount_warn_saturate+0xb1/0x120
CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:refcount_warn_saturate+0xb1/0x120

Call Trace:
 <TASK>
 c_show+0x2fc/0x380 [sunrpc]
 seq_read_iter+0x589/0x770
 seq_read+0x1e5/0x270
 proc_reg_read+0xe1/0x140
 vfs_read+0x125/0x530
 ksys_read+0xc1/0x160
 do_syscall_64+0x5f/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/02999e135b013d85c6df738746e8e24699befee4; https://git.kernel.org/stable/c/068c0b50f3f700b94f78850834cd91ae3b34c2c1; https://git.kernel.org/stable/c/2862eee078a4d2d1f584e7f24fa50dddfa5f3471
CVE: CVE-2024-53175
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ipc: fix memleak if msg_init_ns failed in create_ipc_ns

Percpu memory allocation may failed during create_ipc_ns however this
fail is not handled properly since ipc sysctls and mq sysctls is not
released properly. Fix this by release these two resource when failure.

Here is the kmemleak stack when percpu failed:

unreferenced object 0xffff88819de2a600 (size 512):
  comm "shmem_2nstest", pid 120711, jiffies[PII_REDACTED]
  hex dump (first 32 bytes):
    60 aa 9d 84 ff ff ff ff fc 18 48 b2 84 88 ff ff  `.........H.....
    04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff  ........ .V.....
  backtrace (crc be7cba35):
    [<ffffffff81b43f83>] __kmalloc_node_track_caller_noprof+0x333/0x420
    [<ffffffff81a52e56>] kmemdup_noprof+0x26/0x50
    [<ffffffff821b2f37>] setup_mq_sysctls+0x57/0x1d0
    [<ffffffff821b29cc>] copy_ipcs+0x29c/0x3b0
    [<ffffffff815d6a10>] create_new_namespaces+0x1d0/0x920
    [<ffffffff815d7449>] copy_namespaces+0x2e9/0x3e0
    [<ffffffff815458f3>] copy_process+0x29f3/0x7ff0
    [<ffffffff8154b080>] kernel_clone+0xc0/0x650
    [<ffffffff8154b6b1>] __do_sys_clone+0xa1/0xe0
    [<ffffffff843df8ff>] do_syscall_64+0xbf/0x1c0
    [<ffffffff846000b0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/10209665b5bf199f8065b2e7d2b2dc6cdf227117; https://git.kernel.org/stable/c/3d230cfd4b9b0558c7b2039ba1def2ce6b6cd158; https://git.kernel.org/stable/c/8fed302872e26c7bf44d855c53a1cde747172d58
CVE: CVE-2024-53176
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: During unmount, ensure all cached dir instances drop their dentry

The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can
race with various cached directory operations, which ultimately results
in dentries not being dropped and these kernel BUGs:

BUG: Dentry ffff88814f37e358{i=[PII_REDACTED]80,n=/}  still in use (2) [unmount of cifs cifs]
VFS: Busy inodes after unmount of cifs (cifs)
------------[ cut here ]------------
kernel BUG at fs/super.c:661!

This happens when a cfid is in the process of being cleaned up when, and
has been removed from the cfids->entries list, including:

- Receiving a lease break from the server
- Server reconnection triggers invalidate_all_cached_dirs(), which
  removes all the cfids from the list
- The laundromat thread decides to expire an old cfid.

To solve these problems, dropping the dentry is done in queued work done
in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()
flushes that workqueue after it drops all the dentries of which it's
aware. This is a global workqueue (rather than scoped to a mount), but
the queued work is minimal.

The final cleanup work for cleaning up a cfid is performed via work
queued in the serverclose_wq workqueue; this is done separate from
dropping the dentries so that close_all_cached_dirs() doesn't block on
any server operations.

Both of these queued works expect to invoked with a cfid reference and
a tcon reference to avoid those objects from being freed while the work
is ongoing.

While we're here, add proper locking to close_all_cached_dirs(), and
locking around the freeing of cfid->dentry.
CVSS Score: 4.7 (MEDIUM)
References: https://git.kernel.org/stable/c/3fa640d035e5ae526769615c35cb9ed4be6e3662; https://git.kernel.org/stable/c/548812afd96982a76a93ba76c0582ea670c40d9e; https://git.kernel.org/stable/c/73934e535cffbda1490fa97d82690a0f9aa73e94
CVE: CVE-2024-53179
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix use-after-free of signing key

Customers have reported use-after-free in @ses->auth_key.response with
SMB2.1 + sign mounts which occurs due to following race:

task A                         task B
cifs_mount()
 dfs_mount_share()
  get_session()
   cifs_mount_get_session()    cifs_send_recv()
    cifs_get_smb_ses()          compound_send_recv()
     cifs_setup_session()        smb2_setup_request()
      kfree_sensitive()           smb2_calc_signature()
                                   crypto_shash_setkey() *UAF*

Fix this by ensuring that we have a valid @ses->auth_key.response by
checking whether @ses->ses_status is SES_GOOD or SES_EXITING with
@ses->ses_lock held.  After commit 24a9799aa8ef ("smb: client: fix UAF
in smb2_reconnect_server()"), we made sure to call ->logoff() only
when @ses was known to be good (e.g. valid ->auth_key.response), so
it's safe to access signing key when @ses->ses_status == SES_EXITING.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/0e2b654a3848bf9da3b0d54c1ccf3f1b8c635591; https://git.kernel.org/stable/c/343d7fe6df9e247671440a932b6a73af4fa86d95; https://git.kernel.org/stable/c/39619c65ab4bbb3e78c818f537687653e112764d
CVE: CVE-2024-53180
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Add sanity NULL check for the default mmap fault handler

A driver might allow the mmap access before initializing its
runtime->dma_area properly.  Add a proper NULL check before passing to
virt_to_page() for avoiding a panic.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0c4c9bf5eab7bee6b606f2abb0993e933b5831a0; https://git.kernel.org/stable/c/832efbb74b1578e3737d593a204d42af8bd1b81b; https://git.kernel.org/stable/c/8799f4332a9fd812eadfbc32fc5104d6292f754f