deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-53222
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

zram: fix NULL pointer in comp_algorithm_show()

LTP reported a NULL pointer dereference as followed:

 CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3
 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __pi_strcmp+0x24/0x140
 lr : zcomp_available_show+0x60/0x100 [zram]
 sp : ffff800088b93b90
 x29: ffff800088b93b90 x28: [PII_REDACTED] x27:[PII_REDACTED]400cc0
 x26:[PII_REDACTED]000ffe x25: ffff80007b3e2388 x24: [PII_REDACTED]
 x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900
 x20: [PII_REDACTED] x19: [PII_REDACTED] x18: [PII_REDACTED]
 x17: [PII_REDACTED] x16: [PII_REDACTED] x15: [PII_REDACTED]
 x14: [PII_REDACTED] x13: [PII_REDACTED] x12: [PII_REDACTED]
 x11: [PII_REDACTED] x10: ffff80007b3e2900 x9 : ffff80007b3cb280
 x8 : [PII_REDACTED] x7 : [PII_REDACTED] x6 : [PII_REDACTED]
 x5 : [PII_REDACTED] x4 : [PII_REDACTED] x3 : 00656c722d6f7a6c
 x2 : [PII_REDACTED] x1 : ffff80007b3e2900 x0 : [PII_REDACTED]
 Call trace:
  __pi_strcmp+0x24/0x140
  comp_algorithm_show+0x40/0x70 [zram]
  dev_attr_show+0x28/0x80
  sysfs_kf_seq_show+0x90/0x140
  kernfs_seq_show+0x34/0x48
  seq_read_iter+0x1d4/0x4e8
  kernfs_fop_read_iter+0x40/0x58
  new_sync_read+0x9c/0x168
  vfs_read+0x1a8/0x1f8
  ksys_read+0x74/0x108
  __arm64_sys_read+0x24/0x38
  invoke_syscall+0x50/0x120
  el0_svc_common.constprop.0+0xc8/0xf0
  do_el0_svc+0x24/0x38
  el0_svc+0x38/0x138
  el0t_64_sync_handler+0xc0/0xc8
  el0t_64_sync+0x188/0x190

The zram->comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if
comp_algorithm_set() has not been called.  User can access the zram device
by sysfs after device_add_disk(), so there is a time window to trigger the
NULL pointer dereference.  Move it ahead device_add_disk() to make sure
when user can access the zram device, it is ready.  comp_algorithm_set()
is protected by zram->init_lock in other places and no such problem.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/843d366ff19708668d95cda16bb8aba109a93dba; https://git.kernel.org/stable/c/c7ee791e538537b281f[PII_REDACTED]6f0a3971bbd; https://git.kernel.org/stable/c/f364cdeb38938f9d03061682b8ff3779dd1730e5
CVE: CVE-2024-53223
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs

Base clocks are the first in being probed and are real dependencies of the
rest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880,
RT305x and RT3883 'xtal' must be defined first since in any other case,
when fixed clocks are probed they are delayed until 'xtal' is probed so the
following warning appears:

 WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138
 Modules linked in:
 CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0
 Stack : 805e58d0 [PII_REDACTED] 8004f950 [PII_REDACTED] [PII_REDACTED]
 80669c54 [PII_REDACTED] 805ae570 [PII_REDACTED] 80669bf8 00000000
 [PII_REDACTED] 805ae570 80669b38 00000020 804db7dc [PII_REDACTED]
 203a6d6d 80669b78 80669e48 [PII_REDACTED] 805ae570 [PII_REDACTED]
 [PII_REDACTED] [PII_REDACTED] [PII_REDACTED] 83fe43b0 00000000
 ...
 Call Trace:
 [<800065d0>] show_stack+0x64/0xf4
 [<804bca14>] dump_stack_lvl+0x38/0x60
 [<800218ac>] __warn+0x94/0xe4
 [<8002195c>] warn_slowpath_fmt+0x60/0x94
 [<80259ff8>] rt3883_bus_recalc_rate+0x98/0x138
 [<80254530>] __clk_register+0x568/0x688
 [<80254838>] of_clk_hw_register+0x18/0x2c
 [<8070b910>] rt2880_clk_of_clk_init_driver+0x18c/0x594
 [<8070b628>] of_clk_init+0x1c0/0x23c
 [<806fc448>] plat_time_init+0x58/0x18c
 [<806fdaf0>] time_init+0x10/0x6c
 [<806f9bc4>] start_kernel+0x458/0x67c

 ---[ end trace [PII_REDACTED] ]---

When this driver was mainlined we could not find any active users of old
ralink SoCs so we cannot perform any real tests for them. Now, one user
of a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and
reported some issues in openWRT:
- https://github.com/openwrt/openwrt/issues/16054

Thus, define a 'rt2880_xtal_recalc_rate()' just returning the expected
frequency 40Mhz and use it along the old ralink SoCs to have a correct
boot trace with no warnings and a working clock plan from the beggining.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/d34db686a3d74bd564bfce2ada15011c556269fc; https://git.kernel.org/stable/c/e29306c0e1ae4b434db32c90705844c77f701be5; https://git.kernel.org/stable/c/fbb13732c6ffa9d58cedafabcd5ce8fd7ef8ae5a
CVE: CVE-2024-53225
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/tegra241-cmdqv: Fix alignment failure at max_n_shift

When configuring a kernel with PAGE_SIZE=4KB, depending on its setting of
CONFIG_CMA_ALIGNMENT, VCMDQ_LOG2SIZE_MAX=19 could fail the alignment test
and trigger a WARN_ON:
    WARNING: at drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3646
    Call trace:
     arm_smmu_init_one_queue+0x15c/0x210
     tegra241_cmdqv_init_structures+0x114/0x338
     arm_smmu_device_probe+0xb48/0x1d90

Fix it by capping max_n_shift to CMDQ_MAX_SZ_SHIFT as SMMUv3 CMDQ does.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/85a1d70b86dbcb84a68e7e4942a[PII_REDACTED]988; https://git.kernel.org/stable/c/a3799717b881aa0f4e722afb70e7b8ba84ae4f36
CVE: CVE-2024-53226
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()

ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.
The driver needs to check whether it is a NULL pointer before
dereferencing it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/35f5b68f63aac61d30ce0b0c6beb09b8845a3e65; https://git.kernel.org/stable/c/52617e76f4963644db71dc0a17e998654dc0c7f4; https://git.kernel.org/stable/c/6b0d7d6e6883d0ec70cd7b5a02c47c003d5defe7
CVE: CVE-2024-53227
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: bfa: Fix use-after-free in bfad_im_module_exit()

BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20
Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303

Call Trace:
 <TASK>
 dump_stack_lvl+0x95/0xe0
 print_report+0xcb/0x620
 kasan_report+0xbd/0xf0
 __lock_acquire+0x2aca/0x3a20
 lock_acquire+0x19b/0x520
 _raw_spin_lock+0x2b/0x40
 attribute_container_unregister+0x30/0x160
 fc_release_transport+0x19/0x90 [scsi_transport_fc]
 bfad_im_module_exit+0x23/0x60 [bfa]
 bfad_init+0xdb/0xff0 [bfa]
 do_one_initcall+0xdc/0x550
 do_init_module+0x22d/0x6b0
 load_module+0x4e96/0x5ff0
 init_module_from_file+0xcd/0x130
 idempotent_init_module+0x330/0x620
 __x64_sys_finit_module+0xb3/0x110
 do_syscall_64+0xc1/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 </TASK>

Allocated by task 25303:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x7f/0x90
 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc]
 bfad_im_module_init+0x17/0x80 [bfa]
 bfad_init+0x23/0xff0 [bfa]
 do_one_initcall+0xdc/0x550
 do_init_module+0x22d/0x6b0
 load_module+0x4e96/0x5ff0
 init_module_from_file+0xcd/0x130
 idempotent_init_module+0x330/0x620
 __x64_sys_finit_module+0xb3/0x110
 do_syscall_64+0xc1/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 25303:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x38/0x50
 kfree+0x212/0x480
 bfad_im_module_init+0x7e/0x80 [bfa]
 bfad_init+0x23/0xff0 [bfa]
 do_one_initcall+0xdc/0x550
 do_init_module+0x22d/0x6b0
 load_module+0x4e96/0x5ff0
 init_module_from_file+0xcd/0x130
 idempotent_init_module+0x330/0x620
 __x64_sys_finit_module+0xb3/0x110
 do_syscall_64+0xc1/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Above issue happens as follows:

bfad_init
  error = bfad_im_module_init()
    fc_release_transport(bfad_im_scsi_transport_template);
  if (error)
    goto ext;

ext:
  bfad_im_module_exit();
    fc_release_transport(bfad_im_scsi_transport_template);
    --> Trigger double release

Don't call bfad_im_module_exit() if bfad_im_module_init() failed.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/0ceac8012d3ddea3317f0d82934293d05feb8af1; https://git.kernel.org/stable/c/178b8f38932d635e90f5f0e9af1986c6f4a89271; https://git.kernel.org/stable/c/1ffdde30a90bf8efe8f270407f486706962b3292
CVE: CVE-2024-53228
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: kvm: Fix out-of-bounds array access

In kvm_riscv_vcpu_sbi_init() the entry->ext_idx can contain an
out-of-bound index. This is used as a special marker for the base
extensions, that cannot be disabled. However, when traversing the
extensions, that special marker is not checked prior indexing the
array.

Add an out-of-bounds check to the function.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129, CWE-129
References: https://git.kernel.org/stable/c/332fa4a802b16ccb727199da685294f85f9880cb; https://git.kernel.org/stable/c/3c49e1084a5df99807fc43dd318c491e6cbaa168; https://git.kernel.org/stable/c/b1af648f0d610665c956ea4604d9f797e5c7e991
CVE: CVE-2024-53229
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix the qp flush warnings in req

When the qp is in error state, the status of WQEs in the queue should be
set to error. Or else the following will appear.

[  920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe]
[  920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6
[  920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G           O       6.1.113-storage+ #65
[  920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[  920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe]
[  920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24
[  920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246
[  920.620817] RAX: [PII_REDACTED] RBX:[PII_REDACTED]00000c RCX: [PII_REDACTED]
[  920.621183] RDX: ffff960dc396ebc0 RSI: [PII_REDACTED] RDI: ffff960dc4e2fbac
[  920.621548] RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: ffffffffac406450
[  920.621884] R10: ffffffffac4060c0 R11: [PII_REDACTED] R12: ffff960dc4e2f800
[  920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: [PII_REDACTED]
[  920.622609] FS:  [PII_REDACTED](0000) GS:ffff960ef7d00000(0000) knlGS:[PII_REDACTED]
[  920.622979] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[  920.623245] CR2: 00007fa056965e90 CR3:[PII_REDACTED]7f1000 CR4:[PII_REDACTED]0006e0
[  920.623680] Call Trace:
[  920.623815]  <TASK>
[  920.623933]  ? __warn+0x79/0xc0
[  920.624116]  ? rxe_completer+0x989/0xcc0 [rdma_rxe]
[  920.624356]  ? report_bug+0xfb/0x150
[  920.624594]  ? handle_bug+0x3c/0x60
[  920.624796]  ? exc_invalid_op+0x14/0x70
[  920.624976]  ? asm_exc_invalid_op+0x16/0x20
[  920.625203]  ? rxe_completer+0x989/0xcc0 [rdma_rxe]
[  920.625474]  ? rxe_completer+0x329/0xcc0 [rdma_rxe]
[  920.625749]  rxe_do_task+0x80/0x110 [rdma_rxe]
[  920.626037]  rxe_requester+0x625/0xde0 [rdma_rxe]
[  920.626310]  ? rxe_cq_post+0xe2/0x180 [rdma_rxe]
[  920.626583]  ? do_complete+0x18d/0x220 [rdma_rxe]
[  920.626812]  ? rxe_completer+0x1a3/0xcc0 [rdma_rxe]
[  920.627050]  rxe_do_task+0x80/0x110 [rdma_rxe]
[  920.627285]  tasklet_action_common.constprop.0+0xa4/0x120
[  920.627522]  handle_softirqs+0xc2/0x250
[  920.627728]  ? sort_range+0x20/0x20
[  920.627942]  run_ksoftirqd+0x1f/0x30
[  920.628158]  smpboot_thread_fn+0xc7/0x1b0
[  920.628334]  kthread+0xd6/0x100
[  920.628504]  ? kthread_complete_and_exit+0x20/0x20
[  920.628709]  ret_from_fork+0x1f/0x30
[  920.628892]  </TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/31978d5c5aef034d96fc53b4a9cb3c6e11dbb94d; https://git.kernel.org/stable/c/9e95518eca5ccc0a2f5d99d7b8a142c73ce3f8d0; https://git.kernel.org/stable/c/cc341b5d761a8a16693fe406b8127e4378747f85
CVE: CVE-2024-53230
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()

cpufreq_cpu_get_raw() may return NULL if the cpu is not in
policy->cpus cpu mask and it will cause null pointer dereference,
so check NULL for cppc_get_cpu_cost().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1975b481f644f8f841d9c188e3c214fce187f18b; https://git.kernel.org/stable/c/1a1374bb8c[PII_REDACTED]d849feed500bc61ad535; https://git.kernel.org/stable/c/6be57617a38b3f33266acecdb3c063c1c079aaf7
CVE: CVE-2024-53231
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()

cpufreq_cpu_get_raw() may return NULL if the cpu is not in
policy->cpus cpu mask and it will cause null pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/65fe2f7fdafe2698a[PII_REDACTED]34b3f2e51041e; https://git.kernel.org/stable/c/a357b63fd21e4b2791008c2175ba7a8c235ebce1; https://git.kernel.org/stable/c/a78e[PII_REDACTED]db6e373e86294a85f9d646d35a
CVE: CVE-2024-53232
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/s390: Implement blocking domain

This fixes a crash when surprise hot-unplugging a PCI device. This crash
happens because during hot-unplug __iommu_group_set_domain_nofail()
attaching the default domain fails when the platform no longer
recognizes the device as it has already been removed and we end up with
a NULL domain pointer and UAF. This is exactly the case referred to in
the second comment in __iommu_device_set_domain() and just as stated
there if we can instead attach the blocking domain the UAF is prevented
as this can handle the already removed device. Implement the blocking
domain to use this handling.  With this change, the crash is fixed but
we still hit a warning attempting to change DMA ownership on a blocked
device.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416, CWE-476, CWE-416
References: https://git.kernel.org/stable/c/3be34fa1cdbf180c1a948cfededfdf2cdc497199; https://git.kernel.org/stable/c/bd89d94f3ea6fdaee983cbc69226a00b9bde6d59; https://git.kernel.org/stable/c/ecda483339a5151e3ca30d6b82691ef6f1d17912
CVE: CVE-2024-53233
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

unicode: Fix utf8_load() error path

utf8_load() requests the symbol "utf8_data_table" and then checks if the
requested UTF-8 version is supported. If it's unsupported, it tries to
put the data table using symbol_put(). If an unsupported version is
requested, symbol_put() fails like this:

 kernel BUG at kernel/module/main.c:786!
 RIP: 0010:__symbol_put+0x93/0xb0
 Call Trace:
  <TASK>
  ? __die_body.cold+0x19/0x27
  ? die+0x2e/0x50
  ? do_trap+0xca/0x110
  ? do_error_trap+0x65/0x80
  ? __symbol_put+0x93/0xb0
  ? exc_invalid_op+0x51/0x70
  ? __symbol_put+0x93/0xb0
  ? asm_exc_invalid_op+0x1a/0x20
  ? __pfx_cmp_name+0x10/0x10
  ? __symbol_put+0x93/0xb0
  ? __symbol_put+0x62/0xb0
  utf8_load+0xf8/0x150

That happens because symbol_put() expects the unique string that
identify the symbol, instead of a pointer to the loaded symbol. Fix that
by using such string.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/156bb2c569cd869583c593d27a5bd69e7b2a4264; https://git.kernel.org/stable/c/4387cef540f36c2c[PII_REDACTED]cc2438305a24a0; https://git.kernel.org/stable/c/6504dd27123966dc455494cb55217c04ca479121
CVE: CVE-2024-53234
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: handle NONHEAD !delta[1] lclusters gracefully

syzbot reported a WARNING in iomap_iter_done:
 iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80
 ioctl_fiemap fs/ioctl.c:220 [inline]

Generally, NONHEAD lclusters won't have delta[1]==0, except for crafted
images and filesystems created by pre-1.0 mkfs versions.

Previously, it would immediately bail out if delta[1]==0, which led to
inadequate decompressed lengths (thus FIEMAP is impacted).  Treat it as
delta[1]=1 to work around these legacy mkfs versions.

`lclusterbits > 14` is illegal for compact indexes, error out too.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0bc8061ffc733a0a246b8689b2d32a3e9204f43c; https://git.kernel.org/stable/c/480c6c7b55aeacac800bc2a0d321ff53273045e5; https://git.kernel.org/stable/c/75a0a6dde803e7a3af700da8da9a361b49f69eba
CVE: CVE-2024-53235
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: fix file-backed mounts over FUSE

syzbot reported a null-ptr-deref in fuse_read_args_fill:
 fuse_read_folio+0xb0/0x100 fs/fuse/file.c:905
 filemap_read_folio+0xc6/0x2a0 mm/filemap.c:2367
 do_read_cache_folio+0x263/0x5c0 mm/filemap.c:3825
 read_mapping_folio include/linux/pagemap.h:1011 [inline]
 erofs_bread+0x34d/0x7e0 fs/erofs/data.c:41
 erofs_read_superblock fs/erofs/super.c:281 [inline]
 erofs_fc_fill_super+0x2b9/0x2500 fs/erofs/super.c:625

Unlike most filesystems, some network filesystems and FUSE need
unavoidable valid `file` pointers for their read I/Os [1].
Anyway, those use cases need to be supported too.

[1] https://docs.kernel.org/filesystems/vfs.html
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/3a23787ca8756920d65fda39f41353a4be1d1642; https://git.kernel.org/stable/c/5036f2f024cac40a02ea6ea70de2c3a4407d16bc
CVE: CVE-2024-53236
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

xsk: Free skb when TX metadata options are invalid

When a new skb is allocated for transmitting an xsk descriptor, i.e., for
every non-multibuf descriptor or the first frag of a multibuf descriptor,
but the descriptor is later found to have invalid options set for the TX
metadata, the new skb is never freed. This can leak skbs until the send
buffer is full which makes sending more packets impossible.

Fix this by freeing the skb in the error path if we are currently dealing
with the first frag, i.e., an skb allocated in this iteration of
xsk_build_skb.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0c0d0f42ffa6ac94cd79893b7ed419c15e1b45de; https://git.kernel.org/stable/c/7f0d0dd5a7f437d83cff954bc321f1a9b181efd5; https://git.kernel.org/stable/c/d5d346deb65efa8453f8481bcea75c1a590439e7
CVE: CVE-2024-53239
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: 6fire: Release resources at card release

The current 6fire code tries to release the resources right after the
call of usb6fire_chip_abort().  But at this moment, the card object
might be still in use (as we're calling snd_card_free_when_closed()).

For avoid potential UAFs, move the release of resources to the card's
private_free instead of the manual call of usb6fire_chip_destroy() at
the USB disconnect callback.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/0df7f4b5cc10f5adf98be0845372e9eef7bb5b09; https://git.kernel.org/stable/c/273eec23467dfbfbd0e4c10302579ba441fb1e13; https://git.kernel.org/stable/c/57860a80f03f9dc69a34a5c37b0941ad032a0a8c
CVE: CVE-2024-56531
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: caiaq: Use snd_card_free_when_closed() at disconnection

The USB disconnect callback is supposed to be short and not too-long
waiting.  OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long.  It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.

An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed().  This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.

This patch also splits the code to the disconnect and the free phases;
the former is called immediately at the USB disconnect callback while
the latter is called from the card destructor.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/237f3faf0177bdde728fa3106d730d806436aa4d; https://git.kernel.org/stable/c/3993edf44d3df7b6e8c753eac6ac8783473fcbab; https://git.kernel.org/stable/c/4507a8b9b30344c5ddd8219945f446d47e966a6d
CVE: CVE-2024-56532
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: us122l: Use snd_card_free_when_closed() at disconnection

The USB disconnect callback is supposed to be short and not too-long
waiting.  OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long.  It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.

An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed().  This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.

The loop of us122l->mmap_count check is dropped as well.  The check is
useless for the asynchronous operation with *_when_closed().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/020cbc4d7414f[PII_REDACTED]e2b7bc5cc607e9ec7; https://git.kernel.org/stable/c/2938dd[PII_REDACTED]133c151dd67bb9bf01cbd390; https://git.kernel.org/stable/c/75f418b249d84021865eaa59515d3ed9b75ce4d6
CVE: CVE-2024-56533
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: usx2y: Use snd_card_free_when_closed() at disconnection

The USB disconnect callback is supposed to be short and not too-long
waiting.  OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long.  It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.

An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed().  This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/24fe9f7ca83ec9acf[PII_REDACTED]51f5cd9ae5c5d; https://git.kernel.org/stable/c/7bd8838c0ea886679a32834fdcacab296d072fbe; https://git.kernel.org/stable/c/befcca1777525e37c659b4129d8ac7463b07ef67