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

um: vector: Do not use drvdata in release

The drvdata is not available in release. Let's just use container_of()
to get the vector_device instance. Otherwise, removing a vector device
will result in a crash:

RIP: 0033:vector_device_release+0xf/0x50
RSP: 00000000e187bc40  EFLAGS: 00010202
RAX:[PII_REDACTED]028f61 RBX:[PII_REDACTED]0f1baf RCX:[PII_REDACTED]0074e0
RDX:[PII_REDACTED]20b9c0 RSI:[PII_REDACTED]551c80 RDI: [PII_REDACTED]
RBP: 00000000e187bc50 R08:[PII_REDACTED]3ad594 R09: 00000000e187bb70
R10:[PII_REDACTED]00135a R11:[PII_REDACTED]3ad422 R12:[PII_REDACTED]3ae028
R13:[PII_REDACTED]87a200 R14:[PII_REDACTED]006d30 R15:[PII_REDACTED]3700b6
Kernel panic - not syncing: Segfault with no mm
CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1
Workqueue: events mc_work_proc
Stack:
 60028f61 623ae028 e187bc80 60276fcd
 6220b9c0 603f5820 623ae[PII_REDACTED]0
 e187bcb0 603a2bcd 623ae[PII_REDACTED]0
Call Trace:
 [<60028f61>] ? vector_device_release+0x0/0x50
 [<60276fcd>] device_release+0x70/0xba
 [<603a2bcd>] kobject_put+0xba/0xe7
 [<60277265>] put_device+0x19/0x1c
 [<60281266>] platform_device_put+0x26/0x29
 [<60281e5f>] platform_device_unregister+0x2c/0x2e
 [<60029422>] vector_remove+0x52/0x58
 [<60031316>] ? mconsole_reply+0x0/0x50
 [<600310c8>] mconsole_remove+0x160/0x1cc
 [<603b19f4>] ? strlen+0x0/0x15
 [<60066611>] ? __dequeue_entity+0x1a9/0x206
 [<600666a7>] ? set_next_entity+0x39/0x63
 [<6006666e>] ? set_next_entity+0x0/0x63
 [<60038fa6>] ? um_set_signals+0x0/0x43
 [<6003070c>] mc_work_proc+0x77/0x91
 [<60057664>] process_scheduled_works+0x1b3/0x2dd
 [<60055f32>] ? assign_work+0x0/0x58
 [<60057f0a>] worker_thread+0x1e9/0x293
 [<6005406f>] ? set_pf_worker+0x0/0x64
 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d
 [<6005d748>] ? kthread_exit+0x0/0x3a
 [<60057d21>] ? worker_thread+0x0/0x293
 [<6005dbf1>] kthread+0x126/0x12b
 [<600219c5>] new_thread_handler+0x85/0xb6
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/12f52e373d63f008ee386f371bdd82a3a3779199; https://git.kernel.org/stable/c/35f8f72b45791a6a71b81140c59d02a6183b6f3b; https://git.kernel.org/stable/c/376c7f0beb8f6f3800fc3013ef2f422d0cbfbf92
CVE: CVE-2024-53183
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

um: net: Do not use drvdata in release

The drvdata is not available in release. Let's just use container_of()
to get the uml_net instance. Otherwise, removing a network device will
result in a crash:

RIP: 0033:net_device_release+0x10/0x6f
RSP: 00000000e20c7c40  EFLAGS: 00010206
RAX:[PII_REDACTED]02e4e7 RBX:[PII_REDACTED]0f1baf RCX:[PII_REDACTED]4074e0
RDX: [PII_REDACTED] RSI:[PII_REDACTED]551c80 RDI:[PII_REDACTED]7af028
RBP: 00000000e20c7c50 R08:[PII_REDACTED]3ad594 R09: 00000000e20c7b70
R10:[PII_REDACTED]00135a R11:[PII_REDACTED]3ad422 R12: [PII_REDACTED]
R13:[PII_REDACTED]c7af00 R14:[PII_REDACTED]406d60 R15:[PII_REDACTED]7700b6
Kernel panic - not syncing: Segfault with no mm
CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1
Workqueue: events mc_work_proc
Stack:
 627af028 62c7af00 e20c7c80 60276fcd
 62778000 603f5820 627af[PII_REDACTED]0
 e20c7cb0 603a2bcd 627af[PII_REDACTED]0
Call Trace:
 [<60276fcd>] device_release+0x70/0xba
 [<603a2bcd>] kobject_put+0xba/0xe7
 [<60277265>] put_device+0x19/0x1c
 [<60281266>] platform_device_put+0x26/0x29
 [<60281e5f>] platform_device_unregister+0x2c/0x2e
 [<6002ec9c>] net_remove+0x63/0x69
 [<60031316>] ? mconsole_reply+0x0/0x50
 [<600310c8>] mconsole_remove+0x160/0x1cc
 [<60087d40>] ? __remove_hrtimer+0x38/0x74
 [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98
 [<6006b3cf>] ? dl_server_stop+0x3f/0x48
 [<6006b390>] ? dl_server_stop+0x0/0x48
 [<600672e8>] ? dequeue_entities+0x327/0x390
 [<60038fa6>] ? um_set_signals+0x0/0x43
 [<6003070c>] mc_work_proc+0x77/0x91
 [<60057664>] process_scheduled_works+0x1b3/0x2dd
 [<60055f32>] ? assign_work+0x0/0x58
 [<60057f0a>] worker_thread+0x1e9/0x293
 [<6005406f>] ? set_pf_worker+0x0/0x64
 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d
 [<6005d748>] ? kthread_exit+0x0/0x3a
 [<60057d21>] ? worker_thread+0x0/0x293
 [<6005dbf1>] kthread+0x126/0x12b
 [<600219c5>] new_thread_handler+0x85/0xb6
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/160cd5f956d191eb97664afd31ca59284c08d876; https://git.kernel.org/stable/c/1635d9a0ff1b8bd7aa4767d4ea7b3de72cd36f28; https://git.kernel.org/stable/c/468c2e5394afc848efb1eae6e1961a3c855cf35e
CVE: CVE-2024-53184
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

um: ubd: Do not use drvdata in release

The drvdata is not available in release. Let's just use container_of()
to get the ubd instance. Otherwise, removing a ubd device will result
in a crash:

RIP: 0033:blk_mq_free_tag_set+0x1f/0xba
RSP: 00000000e2083bf0  EFLAGS: 00010246
RAX:[PII_REDACTED]21463a RBX: [PII_REDACTED] RCX:[PII_REDACTED]604d00
RDX: [PII_REDACTED] RSI:[PII_REDACTED]5241a0 RDI: [PII_REDACTED]
RBP: 00000000e2083c10 R08: [PII_REDACTED] R09:[PII_REDACTED]1603f7
R10:[PII_REDACTED]00133a R11:[PII_REDACTED]38c4bd R12: [PII_REDACTED]
R13:[PII_REDACTED]213a5c R14:[PII_REDACTED]405d20 R15:[PII_REDACTED]4f7aa0
Kernel panic - not syncing: Segfault with no mm
CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1
Workqueue: events mc_work_proc
Stack:
 00000000 604f7ef0 62c5d000 62405d20
 e2083c30 6002c776 6002c755 600e47ff
 e2083c60 6025ffe3 04208060 603d36e0
Call Trace:
 [<6002c776>] ubd_device_release+0x21/0x55
 [<6002c755>] ? ubd_device_release+0x0/0x55
 [<600e47ff>] ? kfree+0x0/0x100
 [<6025ffe3>] device_release+0x70/0xba
 [<60381d6a>] kobject_put+0xb5/0xe2
 [<6026027b>] put_device+0x19/0x1c
 [<6026a036>] platform_device_put+0x26/0x29
 [<6026ac5a>] platform_device_unregister+0x2c/0x2e
 [<6002c52e>] ubd_remove+0xb8/0xd6
 [<6002bb74>] ? mconsole_reply+0x0/0x50
 [<6002b926>] mconsole_remove+0x160/0x1cc
 [<6002bbbc>] ? mconsole_reply+0x48/0x50
 [<6003379c>] ? um_set_signals+0x3b/0x43
 [<60061c55>] ? update_min_vruntime+0x14/0x70
 [<6006251f>] ? dequeue_task_fair+0x164/0x235
 [<600620aa>] ? update_cfs_group+0x0/0x40
 [<603a0e77>] ? __schedule+0x0/0x3ed
 [<60033761>] ? um_set_signals+0x0/0x43
 [<6002af6a>] mc_work_proc+0x77/0x91
 [<600520b4>] process_scheduled_works+0x1af/0x2c3
 [<6004ede3>] ? assign_work+0x0/0x58
 [<600527a1>] worker_thread+0x2f7/0x37a
 [<6004ee3b>] ? set_pf_worker+0x0/0x64
 [<6005765d>] ? arch_local_irq_save+0x0/0x2d
 [<60058e07>] ? kthread_exit+0x0/0x3a
 [<600524aa>] ? worker_thread+0x0/0x37a
 [<60058f9f>] kthread+0x130/0x135
 [<6002068e>] new_thread_handler+0x85/0xb6
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/16cf[PII_REDACTED]a9f20b3dd224c06d482648f9e2; https://git.kernel.org/stable/c/23d742a3fcd4781eed015a3a93e6a0e3ab1ef2a8; https://git.kernel.org/stable/c/2d194d951895df214e066d08146e77cb6e02c1d4
CVE: CVE-2024-53186
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix use-after-free in SMB request handling

A race condition exists between SMB request handling in
`ksmbd_conn_handler_loop()` and the freeing of `ksmbd_conn` in the
workqueue handler `handle_ksmbd_work()`. This leads to a UAF.
- KASAN: slab-use-after-free Read in handle_ksmbd_work
- KASAN: slab-use-after-free in rtlock_slowlock_locked

This race condition arises as follows:
- `ksmbd_conn_handler_loop()` waits for `conn->r_count` to reach zero:
  `wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);`
- Meanwhile, `handle_ksmbd_work()` decrements `conn->r_count` using
  `atomic_dec_return(&conn->r_count)`, and if it reaches zero, calls
  `ksmbd_conn_free()`, which frees `conn`.
- However, after `handle_ksmbd_work()` decrements `conn->r_count`,
  it may still access `conn->r_count_q` in the following line:
  `waitqueue_active(&conn->r_count_q)` or `wake_up(&conn->r_count_q)`
  This results in a UAF, as `conn` has already been freed.

The discovery of this UAF can be referenced in the following PR for
syzkaller's support for SMB requests.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-416, CWE-416
References: https://git.kernel.org/stable/c/96261adb998a3b513468b6ce17dbec76be5507d4; https://git.kernel.org/stable/c/9a8c5d89d327ff58e9b2517f8a6afb4181d32c6e; https://git.kernel.org/stable/c/a96f9eb7add30ba0fafcfe7b7aca[PII_REDACTED]00
CVE: CVE-2024-53187
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring: check for overflows in io_pin_pages

WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144
CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0
Call Trace:
 <TASK>
 __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183
 io_rings_map io_uring/io_uring.c:2611 [inline]
 io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470
 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692
 io_uring_setup io_uring/io_uring.c:3781 [inline]
 ...
 </TASK>

io_pin_pages()'s uaddr parameter came directly from the user and can be
garbage. Don't just add size to it as it can overflow.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/0c0a4eae26ac78379d0c1db053de168a8febc6c9; https://git.kernel.org/stable/c/29eac3eca72d4c2a71122050c37cd7d8f73ac4f3; https://git.kernel.org/stable/c/aaa90844afd499c9142d0199dfda74439314c013
CVE: CVE-2024-53188
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix crash when unbinding

If there is an error during some initialization related to firmware,
the function ath12k_dp_cc_cleanup is called to release resources.
However this is released again when the device is unbinded (ath12k_pci),
and we get:
BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
at RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k]
Call Trace:
ath12k_dp_cc_cleanup
ath12k_dp_free
ath12k_core_deinit
ath12k_pci_remove
...

The issue is always reproducible from a VM because the MSI addressing
initialization is failing.

In order to fix the issue, just set to NULL the released structure in
ath12k_dp_cc_cleanup at the end.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1304446f67863385dc4c914b6e0194f6664ee764; https://git.kernel.org/stable/c/2eec88c0fa63f8ad35704a8c9df0b5bd8694fcda; https://git.kernel.org/stable/c/488d2959c28621e52b3cce118a813a4bc18bb3d1
CVE: CVE-2024-53189
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan

The channels array in the cfg80211_scan_request has a __counted_by
attribute attached to it, which points to the n_channels variable. This
attribute is used in bounds checking, and if it is not set before the
array is filled, then the bounds sanitizer will issue a warning or a
kernel panic if CONFIG_UBSAN_TRAP is set.

This patch sets the size of allocated memory as the initial value for
n_channels. It is updated with the actual number of added elements after
the array is filled.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1a7b62ddf2c7642878c24f0e556041bb58c37527; https://git.kernel.org/stable/c/9c46a3a5b394d6d123866aa44436fc2cd342eb0d; https://git.kernel.org/stable/c/d4ef643ea78c59c22546046c25dc6e[PII_REDACTED]
CVE: CVE-2024-53191
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix warning when unbinding

If there is an error during some initialization related to firmware,
the buffers dp->tx_ring[i].tx_status are released.
However this is released again when the device is unbinded (ath12k_pci),
and we get:
WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80
Call Trace:
free_large_kmalloc
ath12k_dp_free
ath12k_core_deinit
ath12k_pci_remove
...

The issue is always reproducible from a VM because the MSI addressing
initialization is failing.

In order to fix the issue, just set the buffers to NULL after releasing in
order to avoid the double free.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415, CWE-415
References: https://git.kernel.org/stable/c/223b546c6222d42147eff034433002ca5e2e7e09; https://git.kernel.org/stable/c/90556b96338aa6037cd26dac857327fda7c19732; https://git.kernel.org/stable/c/94c9100b600f05a36b33f9ed76dbd6fb0eb25386
CVE: CVE-2024-53192
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access

Flexible-array member `hws` in `struct clk_hw_onecell_data` is annotated
with the `counted_by()` attribute. This means that when memory is
allocated for this array, the _counter_, which in this case is member
`num` in the flexible structure, should be set to the maximum number of
elements the flexible array can contain, or fewer.

In this case, the total number of elements for the flexible array is
determined by variable `clks_num` when allocating heap space via
`devm_kzalloc()`, as shown below:

289         struct loongson2_clk_provider *clp;
	...
296         for (p = data; p->name; p++)
297                 clks_num++;
298
299         clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num),
300                            GFP_KERNEL);

So, `clp->clk_data.num` should be set to `clks_num` or less, and not
exceed `clks_num`, as is currently the case. Otherwise, if data is
written into `clp->clk_data.hws[clks_num]`, the instrumentation
provided by the compiler won't detect the overflow, leading to a
memory corruption bug at runtime.

Fix this issue by setting `clp->clk_data.num` to `clks_num`.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-120
References: https://git.kernel.org/stable/c/02fb4f0084331ef72c28d0c70fcb15d1bea369ec; https://git.kernel.org/stable/c/1bf[PII_REDACTED]c3abd9d233886a05f6966fbf0c7; https://git.kernel.org/stable/c/b96fc194984d0c82de1ca2b4166b35b1298b216c
CVE: CVE-2024-53193
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider

Some heap space is allocated for the flexible structure `struct
clk_hw_onecell_data` and its flexible-array member `hws` through
the composite structure `struct loongson2_clk_provider` in function
`loongson2_clk_probe()`, as shown below:

289         struct loongson2_clk_provider *clp;
	...
296         for (p = data; p->name; p++)
297                 clks_num++;
298
299         clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num),
300                            GFP_KERNEL);

Then some data is written into the flexible array:

350                 clp->clk_data.hws[p->id] = hw;

This corrupts `clk_lock`, which is the spinlock variable immediately
following the `clk_data` member in `struct loongson2_clk_provider`:

struct loongson2_clk_provider {
	void __iomem *base;
	struct device *dev;
	struct clk_hw_onecell_data clk_data;
	spinlock_t clk_lock;	/* protect access to DIV registers */
};

The problem is that the flexible structure is currently placed in the
middle of `struct loongson2_clk_provider` instead of at the end.

Fix this by moving `struct clk_hw_onecell_data clk_data;` to the end of
`struct loongson2_clk_provider`. Also, add a code comment to help
prevent this from happening again in case new members are added to the
structure in the future.

This change also fixes the following -Wflex-array-member-not-at-end
warning:

drivers/clk/clk-loongson2.c:32:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/145de18065b9840687d9b4e63746238c1da25d22; https://git.kernel.org/stable/c/6e4bf018bb040955da53dae9f8628ef8fcec2dbe; https://git.kernel.org/stable/c/[PII_REDACTED]5f2ba7deda14901d9fff528a180099
CVE: CVE-2024-53196
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Don't retire aborted MMIO instruction

Returning an abort to the guest for an unsupported MMIO access is a
documented feature of the KVM UAPI. Nevertheless, it's clear that this
plumbing has seen limited testing, since userspace can trivially cause a
WARN in the MMIO return:

  WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536
  Call trace:
   kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536
   kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133
   kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487
   __do_sys_ioctl fs/ioctl.c:51 [inline]
   __se_sys_ioctl fs/ioctl.c:893 [inline]
   __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893
   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
   invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
   el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132
   do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
   el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712
   el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730
   el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

The splat is complaining that KVM is advancing PC while an exception is
pending, i.e. that KVM is retiring the MMIO instruction despite a
pending synchronous external abort. Womp womp.

Fix the glaring UAPI bug by skipping over all the MMIO emulation in
case there is a pending synchronous exception. Note that while userspace
is capable of pending an asynchronous exception (SError, IRQ, or FIQ),
it is still safe to retire the MMIO instruction in this case as (1) they
are by definition asynchronous, and (2) KVM relies on hardware support
for pending/delivering these exceptions instead of the software state
machine for advancing PC.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1e46460efe1ef9a31748de7675ff8fe0d8601af2; https://git.kernel.org/stable/c/6af853cf5f897d55f42e9166f4db50e84e404fb3; https://git.kernel.org/stable/c/d0571c3add987bcb69c2ffd7a70c998bf8ce60fb
CVE: CVE-2024-53197
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices

A bogus device can provide a bNumConfigurations value that exceeds the
initial value used in usb_get_configuration for allocating dev->config.

This can lead to out-of-bounds accesses later, e.g. in
usb_destroy_configuration.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0b4ea4bfe16566b84645ded1403756a2dc4e0f19; https://git.kernel.org/stable/c/379d3b9799d9da953391e973b934764f01e03960; https://git.kernel.org/stable/c/62dc01c83fa71e10446ee4c31e0e3d5d1291e865
CVE: CVE-2024-53198
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

xen: Fix the issue of resource not being properly released in xenbus_dev_probe()

This patch fixes an issue in the function xenbus_dev_probe(). In the
xenbus_dev_probe() function, within the if (err) branch at line 313, the
program incorrectly returns err directly without releasing the resources
allocated by err = drv->probe(dev, id). As the return value is non-zero,
the upper layers assume the processing logic has failed. However, the probe
operation was performed earlier without a corresponding remove operation.
Since the probe actually allocates resources, failing to perform the remove
operation could lead to problems.

To fix this issue, we followed the resource release logic of the
xenbus_dev_remove() function by adding a new block fail_remove before the
fail_put block. After entering the branch if (err) at line 313, the
function will use a goto statement to jump to the fail_remove block,
ensuring that the previously acquired resources are correctly released,
thus preventing the reference count leak.

This bug was identified by an experimental static analysis tool developed
by our team. The tool specializes in analyzing reference count operations
and detecting potential issues where resources are not properly managed.
In this case, the tool flagged the missing release operation as a
potential problem, which led to the development of this patch.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45; https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc; https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e
CVE: CVE-2024-53199
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: imx-audmix: Add NULL check in imx_audmix_probe

devm_kasprintf() can return a NULL pointer on failure,but this
returned value in imx_audmix_probe() is not checked.
Add NULL check in imx_audmix_probe(), to handle kernel NULL
pointer dereference error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/c040cbe2e13da6454ae4748e04e53d885e1c9603; https://git.kernel.org/stable/c/dc5aa71f39b44d8117b2417dafd0e2884a75dd37; https://git.kernel.org/stable/c/e038f43edaf0083f6aa7c9415d86cf28dfd152f9
CVE: CVE-2024-53200
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp

This commit addresses a null pointer dereference issue in
hwss_setup_dpp(). The issue could occur when pipe_ctx->plane_state is
null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null
before accessing. This prevents a null pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/020002c76147ecfdafe95c44abd3240e216b6316; https://git.kernel.org/stable/c/0dd3d1de7a5957804ccd58c1b252f9e34710e3f6; https://git.kernel.org/stable/c/2bc96c95070571c6c824e0d4c7783bee25a37876
CVE: CVE-2024-53201
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix null check for pipe_ctx->plane_state in dcn20_program_pipe

This commit addresses a null pointer dereference issue in
dcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ("drm/amd/display:
Add null check for pipe_ctx->plane_state in dcn20_program_pipe")
partially fixed the null pointer dereference issue. However, in
dcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, and
plane_state is accessed again through pipe_ctx. Multiple if statements
directly call attributes of plane_state, leading to potential null
pointer dereference issues. This patch adds necessary null checks to
ensure stability.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]171cd5b[PII_REDACTED]0fb2ae5c87d40; https://git.kernel.org/stable/c/6a057072ddd[PII_REDACTED]7dd880903e8fa23f36; https://git.kernel.org/stable/c/6b4ee2560d4d8de2688da68cd[PII_REDACTED]e0876
CVE: CVE-2024-53202
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware_loader: Fix possible resource leak in fw_log_firmware_info()

The alg instance should be released under the exception path, otherwise
there may be resource leak here.

To mitigate this, free the alg instance with crypto_free_shash when kmalloc
fails.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/369a9c046c2fdfe037f05b43b84c386bdbccc103; https://git.kernel.org/stable/c/789a72498d32f88d24371c10985aceb46397056c; https://git.kernel.org/stable/c/eb5d67d00ad17a5bd0920f455160dc2ccbd2dc78