deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-53999
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: TC, Fix internal port memory leak

The flow rule can be splited, and the extra post_act rules are added
to post_act table. It's possible to trigger memleak when the rule
forwards packets from internal port and over tunnel, in the case that,
for example, CT 'new' state offload is allowed. As int_port object is
assigned to the flow attribute of post_act rule, and its refcnt is
incremented by mlx5e_tc_int_port_get(), but mlx5e_tc_int_port_put() is
not called, the refcnt is never decremented, then int_port is never
freed.

The kmemleak reports the following error:
unreferenced object 0xffff888128204b80 (size 64):
  comm "handler20", pid 50121, jiffies[PII_REDACTED] (age 642.932s)
  hex dump (first 32 bytes):
    01 00 00 00 19 00 00 00 03 f0 00 00 04 00 00 00  ................
    98 77 67 41 81 88 ff ff 98 77 67 41 81 88 ff ff  .wgA.....wgA....
  backtrace:
    [<00000000e992680d>] kmalloc_trace+0x27/0x120
    [<000000009e945a98>] mlx5e_tc_int_port_get+0x3f3/0xe20 [mlx5_core]
    [<[PII_REDACTED]a537f0>] mlx5e_tc_add_fdb_flow+0x473/0xcf0 [mlx5_core]
    [<[PII_REDACTED]c2cec6>] __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core]
    [<000000005cc84048>] mlx5e_configure_flower+0xd40/0x4c40 [mlx5_core]
    [<000000004f8a2031>] mlx5e_rep_indr_offload.isra.0+0x10e/0x1c0 [mlx5_core]
    [<000000007df797dc>] mlx5e_rep_indr_setup_tc_cb+0x90/0x130 [mlx5_core]
    [<[PII_REDACTED]c15cc3>] tc_setup_cb_add+0x1cf/0x410
    [<00000000a63305b4>] fl_hw_replace_filter+0x38f/0x670 [cls_flower]
    [<000000008bc9e77c>] fl_change+0x1fd5/0x4430 [cls_flower]
    [<00000000e7f766e4>] tc_new_tfilter+0x867/0x2010
    [<00000000e101c0ef>] rtnetlink_rcv_msg+0x6fc/0x9f0
    [<00000000e1111d44>] netlink_rcv_skb+0x12c/0x360
    [<[PII_REDACTED]dd6c8b>] netlink_unicast+0x438/0x710
    [<00000000fc568f70>] netlink_sendmsg+0x794/0xc50
    [<[PII_REDACTED]e92590>] sock_sendmsg+0xc5/0x190

So fix this by moving int_port cleanup code to the flow attribute
free helper, which is used by all the attribute free cases.
References: https://git.kernel.org/stable/c/ac5da544a3c2047cbfd715acd9cec8380d7fe5c6; https://git.kernel.org/stable/c/bc1918bac0f30e3f551ef5649b53062917db55fa
CVE: CVE-2023-54000
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix deadlock issue when externel_lb and reset are executed together

When externel_lb and reset are executed together, a deadlock may
occur:
[ 3147.217009] INFO: task kworker/u321:0:7 blocked for more than 120 seconds.
[ 3147.230483] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 3147.238999] task:kworker/u321:0  state:D stack:    0 pid:    7 ppid:     2 flags:0x00000008
[ 3147.248045] Workqueue: hclge hclge_service_task [hclge]
[ 3147.253957] Call trace:
[ 3147.257093]  __switch_to+0x7c/0xbc
[ 3147.261183]  __schedule+0x338/0x6f0
[ 3147.265357]  schedule+0x50/0xe0
[ 3147.269185]  schedule_preempt_disabled+0x18/0x24
[ 3147.274488]  __mutex_lock.constprop.0+0x1d4/0x5dc
[ 3147.279880]  __mutex_lock_slowpath+0x1c/0x30
[ 3147.284839]  mutex_lock+0x50/0x60
[ 3147.288841]  rtnl_lock+0x20/0x2c
[ 3147.292759]  hclge_reset_prepare+0x68/0x90 [hclge]
[ 3147.298239]  hclge_reset_subtask+0x88/0xe0 [hclge]
[ 3147.303718]  hclge_reset_service_task+0x84/0x120 [hclge]
[ 3147.309718]  hclge_service_task+0x2c/0x70 [hclge]
[ 3147.315109]  process_one_work+0x1d0/0x490
[ 3147.319805]  worker_thread+0x158/0x3d0
[ 3147.324240]  kthread+0x108/0x13c
[ 3147.328154]  ret_from_fork+0x10/0x18

In externel_lb process, the hns3 driver call napi_disable()
first, then the reset happen, then the restore process of the
externel_lb will fail, and will not call napi_enable(). When
doing externel_lb again, napi_disable() will be double call,
cause a deadlock of rtnl_lock().

This patch use the HNS3_NIC_STATE_DOWN state to protect the
calling of napi_disable() and napi_enable() in externel_lb
process, just as the usage in ndo_stop() and ndo_start().
References: https://git.kernel.org/stable/c/743f7c1762e098048ede8cdf8c89a118f8d12391; https://git.kernel.org/stable/c/ac6257a3ae5db5193b1f19c268e4f72d274ddb88; https://git.kernel.org/stable/c/d9f609cb50ebab4aa6341112f406bf9d3928ac81
CVE: CVE-2023-54001
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: r8712: Fix memory leak in _r8712_init_xmit_priv()

In the above mentioned routine, memory is allocated in several places.
If the first succeeds and a later one fails, the routine will leak memory.
This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver
to the mainline kernel"). A potential memory leak in
r8712_xmit_resource_alloc() is also addressed.
References: https://git.kernel.org/stable/c/41e05572e871b10dbdc168c76175c97982daf4a4; https://git.kernel.org/stable/c/874555472c736813ba1f4baf0b4c09c8e26d81ea; https://git.kernel.org/stable/c/ac83631230f77dda94154ed0ebfd368fc81c70a3
CVE: CVE-2023-54003
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/core: Fix GID entry ref leak when create_ah fails

If AH create request fails, release sgid_attr to avoid GID entry
referrence leak reported while releasing GID table
References: https://git.kernel.org/stable/c/370280c65c28a515b841c9f2c08524f06182510c; https://git.kernel.org/stable/c/632d6baf8884d803e598bf5164008d23fd9b736c; https://git.kernel.org/stable/c/9c46c49ad3ffe84121715d392b5a0a94f9f10669
CVE: CVE-2023-54005
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

binder: fix memory leak in binder_init()

In binder_init(), the destruction of binder_alloc_shrinker_init() is not
performed in the wrong path, which will cause memory leaks. So this commit
introduces binder_alloc_shrinker_exit() and calls it in the wrong path to
fix that.
References: https://git.kernel.org/stable/c/03eebad96233397f951d8e9fafd82a1674a77284; https://git.kernel.org/stable/c/486dd742ba186ea333664c517d6775b06b1448ca; https://git.kernel.org/stable/c/adb9743d6a08778b78d62d16b4230346d3508986
CVE: CVE-2023-54006
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

af_unix: Fix data-race around unix_tot_inflight.

unix_tot_inflight is changed under spin_lock(unix_gc_lock), but
unix_release_sock() reads it locklessly.

Let's use READ_ONCE() for unix_tot_inflight.

Note that the writer side was marked by commit 9d6d7f1cb67c ("af_unix:
annote lockless accesses to unix_tot_inflight & gc_in_progress")

BUG: KCSAN: data-race in unix_inflight / unix_release_sock

write (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1:
 unix_inflight+0x130/0x180 net/unix/scm.c:64
 unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123
 unix_scm_to_skb net/unix/af_unix.c:1832 [inline]
 unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0x148/0x160 net/socket.c:747
 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493
 ___sys_sendmsg+0xc6/0x140 net/socket.c:2547
 __sys_sendmsg+0x94/0x140 net/socket.c:2576
 __do_sys_sendmsg net/socket.c:2585 [inline]
 __se_sys_sendmsg net/socket.c:2583 [inline]
 __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

read to 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0:
 unix_release_sock+0x608/0x910 net/unix/af_unix.c:671
 unix_release+0x59/0x80 net/unix/af_unix.c:1058
 __sock_release+0x7d/0x170 net/socket.c:653
 sock_close+0x19/0x30 net/socket.c:1385
 __fput+0x179/0x5e0 fs/file_table.c:321
 ____fput+0x15/0x20 fs/file_table.c:349
 task_work_run+0x116/0x1a0 kernel/task_work.c:179
 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
 exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204
 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
 syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297
 do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

value changed: 0x00000000 -> 0x00000001

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
References: https://git.kernel.org/stable/c/20aa8325464d[PII_REDACTED]eed96ca102a074d853; https://git.kernel.org/stable/c/2d8933ca863e252fb09ad0be483255e3dfeb1f54; https://git.kernel.org/stable/c/31b46d5e7c4e295bd112960614a66a177a057dca
CVE: CVE-2023-54007
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

vmci_host: fix a race condition in vmci_host_poll() causing GPF

During fuzzing, a general protection fault is observed in
vmci_host_poll().

general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x[PII_REDACTED]0000c8-0x[PII_REDACTED]0000cf]
RIP: 0010:__lock_acquire+0xf3/0x5e00 kernel/locking/lockdep.c:4926
<- omitting registers ->
Call Trace:
 <TASK>
 lock_acquire+0x1a4/0x4a0 kernel/locking/lockdep.c:5672
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0xb3/0x100 kernel/locking/spinlock.c:162
 add_wait_queue+0x3d/0x260 kernel/sched/wait.c:22
 poll_wait include/linux/poll.h:49 [inline]
 vmci_host_poll+0xf8/0x2b0 drivers/misc/vmw_vmci/vmci_host.c:174
 vfs_poll include/linux/poll.h:88 [inline]
 do_pollfd fs/select.c:873 [inline]
 do_poll fs/select.c:921 [inline]
 do_sys_poll+0xc7c/0x1aa0 fs/select.c:1015
 __do_sys_ppoll fs/select.c:1121 [inline]
 __se_sys_ppoll+0x2cc/0x330 fs/select.c:1101
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Example thread interleaving that causes the general protection fault
is as follows:

CPU1 (vmci_host_poll)               CPU2 (vmci_host_do_init_context)
-----                               -----
// Read uninitialized context
context = vmci_host_dev->context;
                                    // Initialize context
                                    vmci_host_dev->context = vmci_ctx_create();
                                    vmci_host_dev->ct_type = VMCIOBJ_CONTEXT;

if (vmci_host_dev->ct_type == VMCIOBJ_CONTEXT) {
    // Dereferencing the wrong pointer
    poll_wait(..., &context->host_context);
}

In this scenario, vmci_host_poll() reads vmci_host_dev->context first,
and then reads vmci_host_dev->ct_type to check that
vmci_host_dev->context is initialized. However, since these two reads
are not atomically executed, there is a chance of a race condition as
described above.

To fix this race condition, read vmci_host_dev->context after checking
the value of vmci_host_dev->ct_type so that vmci_host_poll() always
reads an initialized context.
References: https://git.kernel.org/stable/c/2053e93ac15519ed1f1fe6eba79a33a4963be4a3; https://git.kernel.org/stable/c/67e35824f861a05b44b19d38e16a83f653bd9d92; https://git.kernel.org/stable/c/770d30b1355c6c8879973dd054fca9168def182c
CVE: CVE-2023-54009
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

i2c: cadence: cdns_i2c_master_xfer(): Fix runtime PM leak on error path

The cdns_i2c_master_xfer() function gets a runtime PM reference when the
function is entered. This reference is released when the function is
exited. There is currently one error path where the function exits
directly, which leads to a leak of the runtime PM reference.

Make sure that this error path also releases the runtime PM reference.
References: https://git.kernel.org/stable/c/2d65599ad1e4f195bbb80752cd5cbc2f1a018dba; https://git.kernel.org/stable/c/5b14d7c6ba0ba5d167f5ef588ca6dfe1af6dd0aa; https://git.kernel.org/stable/c/a712b5a95270e62209f5c2201c774f708f75234e
CVE: CVE-2023-54010
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPICA: ACPICA: check null return of ACPI_ALLOCATE_ZEROED in acpi_db_display_objects

ACPICA commit 0d5f467d6a0ba852ea3aad68663cbcbd43300fd4

ACPI_ALLOCATE_ZEROED may fails, object_info might be null and will cause
null pointer dereference later.
References: https://git.kernel.org/stable/c/35d67ffad6f5d78dbd800d354f5334c7b71a19e0; https://git.kernel.org/stable/c/978e0d05547ae707d51a942fc7e85a34e181ee6f; https://git.kernel.org/stable/c/ae5a0eccc85fc960834dd66e3befc2728284b86c
CVE: CVE-2023-54011
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: mpi3mr: Fix an issue found by KASAN

Write only correct size (32 instead of 64 bytes).
References: https://git.kernel.org/stable/c/abfe73c16b295f2213e9bfc0a1df[PII_REDACTED]48; https://git.kernel.org/stable/c/ae7d45f5283d30274039b95d3e6d53d33c66e991; https://git.kernel.org/stable/c/c8755f913a2fc9c168d108ea8c5af04716e8c4a5
CVE: CVE-2023-54012
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net: fix stack overflow when LRO is disabled for virtual interfaces

When the virtual interface's feature is updated, it synchronizes the
updated feature for its own lower interface.
This propagation logic should be worked as the iteration, not recursively.
But it works recursively due to the netdev notification unexpectedly.
This problem occurs when it disables LRO only for the team and bonding
interface type.

       team0
         |
  +------+------+-----+-----+
  |      |      |     |     |
team1  team2  team3  ...  team200

If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGE
event to its own lower interfaces(team1 ~ team200).
It is worked by netdev_sync_lower_features().
So, the NETDEV_FEAT_CHANGE notification logic of each lower interface
work iteratively.
But generated NETDEV_FEAT_CHANGE event is also sent to the upper
interface too.
upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own
lower interfaces again.
lower and upper interfaces receive this event and generate this
event again and again.
So, the stack overflow occurs.

But it is not the infinite loop issue.
Because the netdev_sync_lower_features() updates features before
generating the NETDEV_FEAT_CHANGE event.
Already synchronized lower interfaces skip notification logic.
So, it is just the problem that iteration logic is changed to the
recursive unexpectedly due to the notification mechanism.

Reproducer:

ip link add team0 type team
ethtool -K team0 lro on
for i in {1..200}
do
        ip link add team$i master team0 type team
        ethtool -K team$i lro on
done

ethtool -K team0 lro off

In order to fix it, the notifier_ctx member of bonding/team is introduced.
References: https://git.kernel.org/stable/c/4bb955c4d2830a58c08e2a48ab75d75368e3ff36; https://git.kernel.org/stable/c/6bf00bb3dc7e5b9fb05488e11616e65d64e975fa; https://git.kernel.org/stable/c/9ea0c5f90a27b5b884d880e146e0f65f3052e401
CVE: CVE-2023-54014
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()

Klocwork reported warning of rport maybe NULL and will be dereferenced.
rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.

Check valid rport returned by fc_bsg_to_rport().
References: https://git.kernel.org/stable/c/1b7e5bdf2be22ae8c61bdca5a5f96ec2746e9639; https://git.kernel.org/stable/c/1ccd52b790a66b8b5f75c87eab8c3a37f941a2bf; https://git.kernel.org/stable/c/921d[PII_REDACTED]a92d1178262a633cc88a8e61bd
CVE: CVE-2023-54015
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Devcom, fix error flow in mlx5_devcom_register_device

In case devcom allocation is failed, mlx5 is always freeing the priv.
However, this priv might have been allocated by a different thread,
and freeing it might lead to use-after-free bugs.
Fix it by freeing the priv only in case it was allocated by the
running thread.
References: https://git.kernel.org/stable/c/1e[PII_REDACTED]00205e6683fa924b2654e99f573b; https://git.kernel.org/stable/c/3dfc1004d9afbf689087ae1eafd88f55481984c7; https://git.kernel.org/stable/c/a3a516caef2c5be2f4d171890a8b3415bfab4e5e
CVE: CVE-2023-54016
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix memory leak in rx_desc and tx_desc

Currently when ath12k_dp_cc_desc_init() is called we allocate
memory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), during
descriptor cleanup rx_descs and tx_descs memory is not freed.

This is cause of memory leak. These allocated memory should be
freed in ath12k_dp_cc_cleanup.

In ath12k_dp_cc_desc_init(), we can save base address of rx_descs
and tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs and
tx_descs memory using their base address.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
References: https://git.kernel.org/stable/c/afb522b36e76acaa9f8fc06d0a9742d841c47c16; https://git.kernel.org/stable/c/e16be2d34883eecfe7fd888fcdb76c7a5db5d187
CVE: CVE-2023-54017
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries: fix possible memory leak in ibmebus_bus_init()

If device_register() returns error in ibmebus_bus_init(), name of kobject
which is allocated in dev_set_name() called in device_add() is leaked.

As comment of device_add() says, it should call put_device() to drop
the reference count that was set in device_initialize() when it fails,
so the name can be freed in kobject_cleanup().
References: https://git.kernel.org/stable/c/3cc4c2f6c266fe5b33a7fa797f31e8b3f06ce58c; https://git.kernel.org/stable/c/7ffe14fce7425c32e735bdc44bce425f18976a49; https://git.kernel.org/stable/c/96f27ff732208dce6468016e7a7d5032bd1bfc23
CVE: CVE-2023-54018
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/hdmi: Add missing check for alloc_ordered_workqueue

Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer and cause NULL pointer dereference in `hdmi_hdcp.c` and
`hdmi_hpd.c`.

Patchwork: https://patchwork.freedesktop.org/patch/517211/
References: https://git.kernel.org/stable/c/1bab31a0969ca4ac90907a5d3b44af104229eafd; https://git.kernel.org/stable/c/392f7eb3946ab3780b931af723033e19f82c9134; https://git.kernel.org/stable/c/9a01ecc312e764ec4527ad49105a3ca799f1860c
CVE: CVE-2023-54019
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

sched/psi: use kernfs polling functions for PSI trigger polling

Destroying psi trigger in cgroup_file_release causes UAF issues when
a cgroup is removed from under a polling process. This is happening
because cgroup removal causes a call to cgroup_file_release while the
actual file is still alive. Destroying the trigger at this point would
also destroy its waitqueue head and if there is still a polling process
on that file accessing the waitqueue, it will step on the freed pointer:

do_select
  vfs_poll
                           do_rmdir
                             cgroup_rmdir
                               kernfs_drain_open_files
                                 cgroup_file_release
                                   cgroup_pressure_release
                                     psi_trigger_destroy
                                       wake_up_pollfree(&t->event_wait)
// vfs_poll is unblocked
                                       synchronize_rcu
                                       kfree(t)
  poll_freewait -> UAF access to the trigger's waitqueue head

Patch [1] fixed this issue for epoll() case using wake_up_pollfree(),
however the same issue exists for synchronous poll() case.
The root cause of this issue is that the lifecycles of the psi trigger's
waitqueue and of the file associated with the trigger are different. Fix
this by using kernfs_generic_poll function when polling on cgroup-specific
psi triggers. It internally uses kernfs_open_node->poll waitqueue head
with its lifecycle tied to the file's lifecycle. This also renders the
fix in [1] obsolete, so revert it.

[1] commit c2dbe32d5db5 ("sched/psi: Fix use-after-free in ep_remove_wait_queue()")
References: https://git.kernel.org/stable/c/92cc0153324b6ae8577a39f5bf2cd83c9a34ea6a; https://git.kernel.org/stable/c/aff037078ecaecf34a7c2afab1341815f90fba5e; https://git.kernel.org/stable/c/d124ab17024cc85a1079b7810a018a497ebc13da
CVE: CVE-2023-54020
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: sf-pdma: pdma_desc memory leak fix

Commit b2cc5c465c2c ("dmaengine: sf-pdma: Add multithread support for a
DMA channel") changed sf_pdma_prep_dma_memcpy() to unconditionally
allocate a new sf_pdma_desc each time it is called.

The driver previously recycled descs, by checking the in_use flag, only
allocating additional descs if the existing one was in use. This logic
was removed in commit b2cc5c465c2c ("dmaengine: sf-pdma: Add multithread
support for a DMA channel"), but sf_pdma_free_desc() was not changed to
handle the new behaviour.

As a result, each time sf_pdma_prep_dma_memcpy() is called, the previous
descriptor is leaked, over time leading to memory starvation:

  unreferenced object 0xffffffe008447300 (size 192):
  comm "irq/39-mchp_dsc", pid 343, jiffies[PII_REDACTED] (age 981.200s)
  hex dump (first 32 bytes):
    00 00 00 ff 00 00 00 00 b8 c1 00 00 00 00 00 00  ................
    00 00 70 08 10 00 00 00 00 00 00 c0 00 00 00 00  ..p.............
  backtrace:
    [<[PII_REDACTED]4a04f4>] kmemleak_alloc+0x1e/0x28
    [<[PII_REDACTED]8927a7>] kmem_cache_alloc+0x11e/0x178
    [<000000002aea8d16>] sf_pdma_prep_dma_memcpy+0x40/0x112

Add the missing kfree() to sf_pdma_free_desc(), and remove the redundant
in_use flag.
References: https://git.kernel.org/stable/c/03fece43fa109beba7cc9948c02f5e2d1205d607; https://git.kernel.org/stable/c/8bd5040bd43f2b5ba3c898b09a3197a0c7ace126; https://git.kernel.org/stable/c/ad222c9af25e3f074c180e389b3477dce42afc4f
CVE: CVE-2023-54021
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: set goal start correctly in ext4_mb_normalize_request

We need to set ac_g_ex to notify the goal start used in
ext4_mb_find_by_goal. Set ac_g_ex instead of ac_f_ex in
ext4_mb_normalize_request.
Besides we should assure goal start is in range [first_data_block,
blocks_count) as ext4_mb_initialize_context does.

[ Added a check to make sure size is less than ar->pright; otherwise
  we could end up passing an underflowed value of ar->pright - size to
  ext4_get_group_no_and_offset(), which will trigger a BUG_ON later on.
  - TYT ]
References: https://git.kernel.org/stable/c/2479bb6cbdb4d56b807bbe5229e3e26a6f1f4530; https://git.kernel.org/stable/c/390eee955d4de4662db5e3e9e9a9eae020432cb7; https://git.kernel.org/stable/c/3ca3005b502ca8ea87d6a344323b179b48c4e4a3