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

isofs: avoid memory leak in iocharset

A memleak was found as below:

unreferenced object 0xffff0000d10164d8 (size 8):
  comm "pool-udisksd", pid 108217, jiffies[PII_REDACTED]
  hex dump (first 8 bytes):
    75 74 66 38 00 cc cc cc                          utf8....
  backtrace (crc de430d31):
    [<ffff800081046e6c>] kmemleak_alloc+0xb8/0xc8
    [<ffff8000803e6c3c>] __kmalloc_node_track_caller_noprof+0x380/0x474
    [<ffff800080363b74>] kstrdup+0x70/0xfc
    [<ffff80007bb3c6a4>] isofs_parse_param+0x228/0x2c0 [isofs]
    [<ffff8000804d7f68>] vfs_parse_fs_param+0xf4/0x164
    [<ffff8000804d8064>] vfs_parse_fs_string+0x8c/0xd4
    [<ffff8000804d815c>] vfs_parse_monolithic_sep+0xb0/0xfc
    [<ffff8000804d81d8>] generic_parse_monolithic+0x30/0x3c
    [<ffff8000804d8bfc>] parse_monolithic_mount_data+0x40/0x4c
    [<ffff8000804b6a64>] path_mount+0x6c4/0x9ec
    [<ffff8000804b6e38>] do_mount+0xac/0xc4
    [<ffff8000804b7494>] __arm64_sys_mount+0x16c/0x2b0
    [<ffff80008002b8dc>] invoke_syscall+0x7c/0x104
    [<ffff80008002ba44>] el0_svc_common.constprop.1+0xe0/0x104
    [<ffff80008002ba94>] do_el0_svc+0x2c/0x38
    [<ffff[PII_REDACTED]08>] el0_svc+0x3c/0x1b8

The opt->iocharset is freed inside the isofs_fill_super function,
But there may be situations where it's not possible to
enter this function.

For example, in the get_tree_bdev_flags function,when
encountering the situation where "Can't mount, would change RO state,"
In such a case, isofs_fill_super will not have the opportunity
to be called,which means that opt->iocharset will not have the chance
to be freed,ultimately leading to a memory leak.

Let's move the memory freeing of opt->iocharset into
isofs_free_fc function.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0b5bbeee4de616a268db77e2f40f19ab010a367b; https://git.kernel.org/stable/c/0fbab266ca8000333c966f5b58cb9b9cac658573; https://git.kernel.org/stable/c/34f090ddb3630a26e5a6b220bf3bfaf5c7b70393
CVE: CVE-2024-56535
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()

kmalloc may fail, return value might be NULL and will cause
NULL pointer dereference. Add check NULL return of kmalloc in
btc_fw_set_monreg().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]71961f3f4c3bff87b427924b486219; https://git.kernel.org/stable/c/64db1a42d98307001a48cec1b3e68ce9f905e73d; https://git.kernel.org/stable/c/81df5ed446b448bdc327b7c7f0b50121fc1f4aa2
CVE: CVE-2024-56536
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cw1200: Fix potential NULL dereference

A recent refactoring was identified by static analysis to
cause a potential NULL dereference, fix this!
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0ec90ac5f7bd9dd573bd5d964cbdc3beaa93a33e; https://git.kernel.org/stable/c/2b94751626a6d49bbe42a19cc1503bd391016bd5; https://git.kernel.org/stable/c/67c914f2d64b28409796a6b9036c131e93f8af6c
CVE: CVE-2024-56537
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: xlnx: zynqmp_disp: layer may be null while releasing

layer->info can be null if we have an error on the first layer in
zynqmp_disp_create_layers
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/223842c7702b52846b1c5aef8aca7474ec1fd29b; https://git.kernel.org/stable/c/9218be402aeb1999cc119fc616e21c3cc7cdeec0; https://git.kernel.org/stable/c/ce7e62bbd55d20cf250396eb4e8f65b3b5a5e685
CVE: CVE-2024-56538
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: zynqmp_kms: Unplug DRM device before removal

Prevent userspace accesses to the DRM device from causing
use-after-frees by unplugging the device before we remove it. This
causes any further userspace accesses to result in an error without
further calls into this driver's internals.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/2e07c88914fc5289c21820b1aa94f058feb38197; https://git.kernel.org/stable/c/4fb97432e28a7e136b2d76135d50e988ada8e1af; https://git.kernel.org/stable/c/692f52aedccbf79b212a1e14e3735192b4c24a7d
CVE: CVE-2024-56539
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()

Replace one-element array with a flexible-array member in `struct
mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):

[  356.775250] ------------[ cut here ]------------
[  356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)
[  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]

The "(size 6)" above is exactly the length of the SSID of the network
this device was connected to. The source of the warning looks like:

    ssid_len = user_scan_in->ssid_list[i].ssid_len;
    [...]
    memcpy(wildcard_ssid_tlv->ssid,
           user_scan_in->ssid_list[i].ssid, ssid_len);

There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this
struct, but it already didn't account for the size of the one-element
array, so it doesn't need to be changed.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1de0ca1d7320a645ba2ee5954f64be08935b002a; https://git.kernel.org/stable/c/581261b2d6fdb4237b24fa13f5a5f87bf2861f2c; https://git.kernel.org/stable/c/5fa329c44e1e635da2541eab28b6cdb8464fc8d1
CVE: CVE-2024-56540
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/ivpu: Prevent recovery invocation during probe and resume

Refactor IPC send and receive functions to allow correct
handling of operations that should not trigger a recovery process.

Expose ivpu_send_receive_internal(), which is now utilized by the D0i3
entry, DCT initialization, and HWS initialization functions.
These functions have been modified to return error codes gracefully,
rather than initiating recovery.

The updated functions are invoked within ivpu_probe() and ivpu_resume(),
ensuring that any errors encountered during these stages result in a proper
teardown or shutdown sequence. The previous approach of triggering recovery
within these functions could lead to a race condition, potentially causing
undefined behavior and kernel crashes due to null pointer dereferences.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-476, CWE-476
References: https://git.kernel.org/stable/c/362ef76020ea6219a4df4ac5b738672b59527239; https://git.kernel.org/stable/c/5eaa497411197c41b0813d61ba3fbd[PII_REDACTED]; https://git.kernel.org/stable/c/cac822772c4dc27a285f09caf30072ab76d2bf38
CVE: CVE-2024-56543
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Skip Rx TID cleanup for self peer

During peer create, dp setup for the peer is done where Rx TID is
updated for all the TIDs. Peer object for self peer will not go through
dp setup.

When core halts, dp cleanup is done for all the peers. While cleanup,
rx_tid::ab is accessed which causes below stack trace for self peer.

WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851
Call Trace:
__warn+0x7b/0x1a0
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
report_bug+0x10b/0x200
handle_bug+0x3f/0x70
exc_invalid_op+0x13/0x60
asm_exc_invalid_op+0x16/0x20
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k]
ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k]
ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k]
ath12k_core_halt+0x3b/0x100 [ath12k]
ath12k_core_reset+0x494/0x4c0 [ath12k]

sta object in peer will be updated when remote peer is created. Hence
use peer::sta to detect the self peer and skip the cleanup.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1a0c640ce1cdcde3eb131a0c1e70ca1ed7cf27cb; https://git.kernel.org/stable/c/a052483d495a4dc62c814f2fd17d0ceb308fc6a6; https://git.kernel.org/stable/c/a1e2d6738b29c74c2024eb23167dfff68aadd984
CVE: CVE-2024-56544
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

udmabuf: change folios array from kmalloc to kvmalloc

When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine,
page_alloc only support 4MB.
If above this, trigger this warn and return NULL.

udmabuf can change size limit, if change it to 3072(3GB), and then alloc
3GB udmabuf, will fail create.

[ 4080.876581] ------------[ cut here ]------------
[ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350
[ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350
[ 4080.879470] Call Trace:
[ 4080.879473]  <TASK>
[ 4080.879473]  ? __alloc_pages+0x2c8/0x350
[ 4080.879475]  ? __warn.cold+0x8e/0xe8
[ 4080.880647]  ? __alloc_pages+0x2c8/0x350
[ 4080.880909]  ? report_bug+0xff/0x140
[ 4080.881175]  ? handle_bug+0x3c/0x80
[ 4080.881556]  ? exc_invalid_op+0x17/0x70
[ 4080.881559]  ? asm_exc_invalid_op+0x1a/0x20
[ 4080.882077]  ? udmabuf_create+0x131/0x400

Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB
memory, each array entry is pointer(8byte), so can save 524288 pages(2GB).

Further more, costly order(order 3) may not be guaranteed that it can be
applied for, due to fragmentation.

This patch change udmabuf array use kvmalloc_array, this can fallback
alloc into vmalloc, which can guarantee allocation for any size and does
not affect the performance of kmalloc allocations.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1c0844c6184e658064e14c[PII_REDACTED]ad3bf84b; https://git.kernel.org/stable/c/2acc6192aa8570661ed37868c02c03002b1dc290; https://git.kernel.org/stable/c/85bb72397cb63649fe493c96e27e1d0e4ed2ff63
CVE: CVE-2024-56545
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: hyperv: streamline driver probe to avoid devres issues

It was found that unloading 'hid_hyperv' module results in a devres
complaint:

 ...
 hv_vmbus: unregistering driver hid_hyperv
 ------------[ cut here ]------------
 WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0
 ...
 Call Trace:
  <TASK>
  ? devres_release_group+0x1f2/0x2c0
  ? __warn+0xd1/0x1c0
  ? devres_release_group+0x1f2/0x2c0
  ? report_bug+0x32a/0x3c0
  ? handle_bug+0x53/0xa0
  ? exc_invalid_op+0x18/0x50
  ? asm_exc_invalid_op+0x1a/0x20
  ? devres_release_group+0x1f2/0x2c0
  ? devres_release_group+0x90/0x2c0
  ? rcu_is_watching+0x15/0xb0
  ? __pfx_devres_release_group+0x10/0x10
  hid_device_remove+0xf5/0x220
  device_release_driver_internal+0x371/0x540
  ? klist_put+0xf3/0x170
  bus_remove_device+0x1f1/0x3f0
  device_del+0x33f/0x8c0
  ? __pfx_device_del+0x10/0x10
  ? cleanup_srcu_struct+0x337/0x500
  hid_destroy_device+0xc8/0x130
  mousevsc_remove+0xd2/0x1d0 [hid_hyperv]
  device_release_driver_internal+0x371/0x540
  driver_detach+0xc5/0x180
  bus_remove_driver+0x11e/0x2a0
  ? __mutex_unlock_slowpath+0x160/0x5e0
  vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]
  ...

And the issue seems to be that the corresponding devres group is not
allocated. Normally, devres_open_group() is called from
__hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver'
with 'mousevsc_hid_driver' stub and basically re-implements
__hid_device_probe() by calling hid_parse() and hid_hw_start() but not
devres_open_group(). hid_device_probe() does not call __hid_device_probe()
for it. Later, when the driver is removed, hid_device_remove() calls
devres_release_group() as it doesn't check whether hdev->driver was
initially overridden or not.

The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure
timely release of driver-allocated resources") but the commit itself seems
to be correct.

Fix the issue by dropping the 'hid_dev->driver' override and using
hid_register_driver()/hid_unregister_driver() instead. Alternatively, it
would have been possible to rely on the default handling but
HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work
for mousevsc as-is.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/19a9457e5e210e408c1f8865b5d93c5a2c90409d; https://git.kernel.org/stable/c/3d48d0fbaaa74a04fb9092780a3f83dc4f3f8160; https://git.kernel.org/stable/c/66ef47faa90d838cda131fe1f7776456cc3b59f2
CVE: CVE-2024-56546
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()

If we fail to allocate memory for cb_data by kmalloc, the memory
allocation for eve_data is never freed, add the missing kfree()
in the error handling path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/272168927f38bda46f6c1ed5f40de97689e7a5d2; https://git.kernel.org/stable/c/44ed4f90a97ff6f339e50ac01db71544e0990efc; https://git.kernel.org/stable/c/584d420771e1ad2bb74e19a19da8ae0fee0a6e1f
CVE: CVE-2024-56549
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

cachefiles: Fix NULL pointer dereference in object->file

At present, the object->file has the NULL pointer dereference problem in
ondemand-mode. The root cause is that the allocated fd and object->file
lifetime are inconsistent, and the user-space invocation to anon_fd uses
object->file. Following is the process that triggers the issue:

	  [write fd]				[umount]
cachefiles_ondemand_fd_write_iter
				       fscache_cookie_state_machine
					 cachefiles_withdraw_cookie
  if (!file) return -ENOBUFS
					   cachefiles_clean_up_object
					     cachefiles_unmark_inode_in_use
					     fput(object->file)
					     object->file = NULL
  // file NULL pointer dereference!
  __cachefiles_write(..., file, ...)

Fix this issue by add an additional reference count to the object->file
before write/llseek, and decrement after it finished.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/31ad74b20227ce6b40910ff78b1c604e42975cf1; https://git.kernel.org/stable/c/785408bbafcfa24c9fc5b251f03fd0780ce182bd; https://git.kernel.org/stable/c/9582c7664103c9043e80a78f5c382aa6bdd67418
CVE: CVE-2024-12984
Published: 2024-12-27
Description: A vulnerability classified as problematic has been found in Amcrest IP2M-841B, IP2M-841W, IPC-IP2M-841B, IPC-IP3M-943B, IPC-IP3M-943S, IPC-IP3M-HX2B and IPC-IPM-721S up to 20241211. This affects an unknown part of the file /web_caps/webCapsConfig of the component Web Interface. The manipulation leads to information disclosure. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-200, CWE-284
References: https://netsecfish.notion.site/AMCREST-IP-Camera-Information-Disclosure-1596b683e67c8045ad10c16b3eed456f?pvs=4; https://vuldb.com/?ctiid.289377; https://vuldb.com/?id.289377
CVE: CVE-2024-12985
Published: 2024-12-27
Description: A vulnerability classified as critical was found in Overtek OT-E801G OTE801G65.1.1.0. This vulnerability affects unknown code of the file /diag_ping.cmd?action=test&interface=ppp0.1&ipaddr=8.8.8.8%26%26cat%20/etc/passwd&ipversion=4&sessionKey=test. The manipulation leads to os command injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-77, CWE-78
References: https://vuldb.com/?ctiid.289378; https://vuldb.com/?id.289378; https://vuldb.com/?submit.462387
CVE: CVE-2024-56550
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/stacktrace: Use break instead of return statement

arch_stack_walk_user_common() contains a return statement instead of a
break statement in case store_ip() fails while trying to store a callchain
entry of a user space process.
This may lead to a missing pagefault_enable() call.

If this happens any subsequent page fault of the process won't be resolved
by the page fault handler and this in turn will lead to the process being
killed.

Use a break instead of a return statement to fix this.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/20c[PII_REDACTED]7dc7c8145297e60ddc012e18914; https://git.kernel.org/stable/c/588a9836a4ef7ec3bfcffda526dfa399637e6cfc
CVE: CVE-2024-56552
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/guc_submit: fix race around suspend_pending

Currently in some testcases we can trigger:

xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed!
....
WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe]
xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57

Looking at a snippet of corresponding ftrace for this GuC id we can see:

162.673311: xe_sched_msg_add:     dev=0000:03:00.0, gt=1 guc_id=57, opcode=3
162.673317: xe_sched_msg_recv:    dev=0000:03:00.0, gt=1 guc_id=57, opcode=3
162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0
162.674089: xe_exec_queue_kill:   dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0
162.674108: xe_exec_queue_close:  dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0
162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0
162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0

It looks like we try to suspend the queue (opcode=3), setting
suspend_pending and triggering a disable_scheduling. The user then
closes the queue. However the close will also forcefully signal the
suspend fence after killing the queue, later when the G2H response for
disable_scheduling comes back we have now cleared suspend_pending when
signalling the suspend fence, so the disable_scheduling now incorrectly
tries to also deregister the queue. This leads to warnings since the queue
has yet to even be marked for destruction. We also seem to trigger
errors later with trying to double unregister the same queue.

To fix this tweak the ordering when handling the response to ensure we
don't race with a disable_scheduling that didn't actually intend to
perform an unregister.  The destruction path should now also correctly
wait for any pending_disable before marking as destroyed.

(cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/5ddcb50b700221fa7d7be2adcb3d7d7afe8633dd; https://git.kernel.org/stable/c/87651f31ae4e6e6e7e6c7270b9b469405e747407
CVE: CVE-2024-56553
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

binder: fix memleak of proc->delivered_freeze

If a freeze notification is cleared with BC_CLEAR_FREEZE_NOTIFICATION
before calling binder_freeze_notification_done(), then it is detached
from its reference (e.g. ref->freeze) but the work remains queued in
proc->delivered_freeze. This leads to a memory leak when the process
exits as any pending entries in proc->delivered_freeze are not freed:

  unreferenced object 0xffff38e8cfa36180 (size 64):
    comm "binder-util", pid 655, jiffies[PII_REDACTED]
    hex dump (first 32 bytes):
      b8 e9 9e c8 e8 38 ff ff b8 e9 9e c8 e8 38 ff ff  .....8.......8..
      0b 00 00 00 00 00 00 00 3c 1f 4b 00 00 00 00 00  ........<.K.....
    backtrace (crc 95983b32):
      [<000000000d0582cf>] kmemleak_alloc+0x34/0x40
      [<000000009c99a513>] __kmalloc_cache_noprof+0x208/0x280
      [<[PII_REDACTED]3b1704>] binder_thread_write+0xdec/0x439c
      [<000000000cbd33bb>] binder_ioctl+0x1b68/0x22cc
      [<000000002bbedeeb>] __arm64_sys_ioctl+0x124/0x190
      [<00000000b439adee>] invoke_syscall+0x6c/0x254
      [<[PII_REDACTED]3558fc>] el0_svc_common.constprop.0+0xac/0x230
      [<[PII_REDACTED]f72311>] do_el0_svc+0x40/0x58
      [<000000008b872457>] el0_svc+0x38/0x78
      [<00000000ee778653>] el0t_64_sync_handler+0x120/0x12c
      [<00000000a8ec61bf>] el0t_64_sync+0x190/0x194

This patch fixes the leak by ensuring that any pending entries in
proc->delivered_freeze are freed during binder_deferred_release().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/1db76ec2b4b206ff943e292a0b55e68ff3443598; https://git.kernel.org/stable/c/b8b77712142fb146fe18d2253bc8a798d522e427
CVE: CVE-2024-56554
Published: 2024-12-27
Description: In the Linux kernel, the following vulnerability has been resolved:

binder: fix freeze UAF in binder_release_work()

When a binder reference is cleaned up, any freeze work queued in the
associated process should also be removed. Otherwise, the reference is
freed while its ref->freeze.work is still queued in proc->work leading
to a use-after-free issue as shown by the following KASAN report:

  ==================================================================
  BUG: KASAN: slab-use-after-free in binder_release_work+0x398/0x3d0
  Read of size 8 at addr ffff31600ee91488 by task kworker/5:1/211

  CPU: 5 UID: 0 PID: 211 Comm: kworker/5:1 Not tainted 6.11.0-rc7-00382-gfc6c92196396 #22
  Hardware name: linux,dummy-virt (DT)
  Workqueue: events binder_deferred_func
  Call trace:
   binder_release_work+0x398/0x3d0
   binder_deferred_func+0xb60/0x109c
   process_one_work+0x51c/0xbd4
   worker_thread+0x608/0xee8

  Allocated by task 703:
   __kmalloc_cache_noprof+0x130/0x280
   binder_thread_write+0xdb4/0x42a0
   binder_ioctl+0x18f0/0x25ac
   __arm64_sys_ioctl+0x124/0x190
   invoke_syscall+0x6c/0x254

  Freed by task 211:
   kfree+0xc4/0x230
   binder_deferred_func+0xae8/0x109c
   process_one_work+0x51c/0xbd4
   worker_thread+0x608/0xee8
  ==================================================================

This commit fixes the issue by ensuring any queued freeze work is removed
when cleaning up a binder reference.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/7e20434cbca814cb91a0a261ca0106815ef48e5f; https://git.kernel.org/stable/c/fe39e0ea2d0ba7f508ff453c4c9a44a95ec0de29