huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-50169: kernel: vsock: Update rx_bytes on read_skb()
Component: kernel
Severity: Moderate
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-07T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

vsock: Update rx_bytes on read_skb()

Make sure virtio_transport_inc_rx_pkt() and virtio_transport_dec_rx_pkt()
calls are balanced (i.e. virtio_vsock_sock::rx_bytes doesn't lie) after
vsock_transport::read_skb().

While here, also inform the peer that we've freed up space and it has more
credit.

Failing to update rx_bytes after packet is dequeued leads to a warning on
SOCK_STREAM recv():

[  233.396654] rx_queue is empty, but rx_bytes is non-zero
[  233.396702] WARNING: CPU: 11 PID: 40601 at net/vmw_vsock/virtio_transport_common.c:589


Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 66cd51de31c682a311c2fa25c580b7ea45859dd9
CVE-2024-50182: kernel: secretmem: disable memfd_secret() if arch cannot set direct map
Component: kernel
Severity: Moderate
CWE: CWE-20 (Improper Input Validation)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

secretmem: disable memfd_secret() if arch cannot set direct map

Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map().  This
is the case for example on some arm64 configurations, where marking 4k
PTEs in the direct map not present can only be done if the direct map is
set up at 4k granularity in the first place (as ARM's break-before-make
semantics do not easily allow breaking apart large/gigantic pages).

More precisely, on arm64 systems with !can_set_direct_map(),
set_direct_map_invalid_noflush() is a no-op, however it returns success
(0) instead of an error.  This means that memfd_secret will seemingly
"work" (e.g.  syscall succeeds, you can mmap the fd and fault in pages),
but it does not actually achieve its goal of removing its memory from the
direct map.

Note that with this patch, memfd_secret() will start erroring on systems
where can_set_direct_map() returns false (arm64 with
CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and
CONFIG_KFENCE=n), but that still seems better than the current silent
failure.  Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most
arm64 systems actually have a working memfd_secret() and aren't be
affected.

From going through the iterations of the original memfd_secret patch
series, it seems that disabling the syscall in these scenarios was the
intended behavior [1] (preferred over having
set_direct_map_invalid_noflush return an error as that would result in
SIGBUSes at page-fault time), however the check for it got dropped between
v16 [2] and v17 [3], when secretmem moved away from CMA allocations.

[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/
[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t
[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/


Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.169, 6.1.113, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d0ae6ffa1aeb297aef89f49cfb894a83c329ebad
CVE-2024-50186: kernel: net: explicitly clear the sk pointer, when pf-&gt;create fails
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: explicitly clear the sk pointer, when pf->create fails

We have recently noticed the exact same KASAN splat as in commit
6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket
creation fails"). The problem is that commit did not fully address the
problem, as some pf->create implementations do not use sk_common_release
in their error paths.

For example, we can use the same reproducer as in the above commit, but
changing ping to arping. arping uses AF_PACKET socket and if packet_create
fails, it will just sk_free the allocated sk object.

While we could chase all the pf->create implementations and make sure they
NULL the freed sk object on error from the socket, we can't guarantee
future protocols will not make the same mistake.

So it is easier to just explicitly NULL the sk pointer upon return from
pf->create in __sock_create. We do know that pf->create always releases the
allocated sk object on error, so if the pointer is not NULL, it is
definitely dangling.


Affected upstream versions: 5.15.162 < 5.15.168, 6.1.96 < 6.1.113, 6.6.36 < 6.6.57, 6.9.7 < 6.10, 6.10
Fixed upstream versions: 0, 5.15.168, 6.1.113, 6.10, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: daf462ff3cde6ecf22b98d9ae770232c10d28de2
CVE-2024-50189: kernel: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
Component: kernel
Severity: Moderate
CWE: CWE-404 (Improper Resource Shutdown or Release)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()

Using the device-managed version allows to simplify clean-up in probe()
error path.

Additionally, this device-managed ensures proper cleanup, which helps to
resolve memory errors, page faults, btrfs going read-only, and btrfs
disk corruption.


Affected upstream versions: 5.11
Fixed upstream versions: 0, 5.15.168, 6.1.113, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8c6ad37e5882073cab84901a31da9cb22f316276
CVE-2024-50191: kernel: ext4: don&#39;t set SB_RDONLY after filesystem errors
Component: kernel
Severity: Moderate
CWE: CWE-833 (Deadlock)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ext4: don't set SB_RDONLY after filesystem errors

When the filesystem is mounted with errors=remount-ro, we were setting
SB_RDONLY flag to stop all filesystem modifications. We knew this misses
proper locking (sb->s_umount) and does not go through proper filesystem
remount procedure but it has been the way this worked since early ext2
days and it was good enough for catastrophic situation damage
mitigation. Recently, syzbot has found a way (see link) to trigger
warnings in filesystem freezing because the code got confused by
SB_RDONLY changing under its hands. Since these days we set
EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all
filesystem modifications, modifying SB_RDONLY shouldn't be needed. So
stop doing that.


Affected upstream versions: 6.6
Fixed upstream versions: 0, 6.11.4, 6.12, 6.6.57
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9
CVE-2024-50192: kernel: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v4: Don't allow a VMOVP on a dying VPE

Kunkun Jiang reported that there is a small window of opportunity for
userspace to force a change of affinity for a VPE while the VPE has already
been unmapped, but the corresponding doorbell interrupt still visible in
/proc/irq/.

Plug the race by checking the value of vmapp_count, which tracks whether
the VPE is mapped ot not, and returning an error in this case.

This involves making vmapp_count common to both GICv4.1 and its v4.0
ancestor.


Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.10.228, 5.15.169, 6.1.114, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b7d7b7fc876f836f40bf48a87e07ea18756ba196
CVE-2024-50195: kernel: posix-clock: Fix missing timespec64 check in pc_clock_settime()
Component: kernel
Severity: Moderate
CWE: CWE-754 (Improper Check for Unusual or Exceptional Conditions)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

posix-clock: Fix missing timespec64 check in pc_clock_settime()

As Andrew pointed out, it will make sense that the PTP core
checked timespec64 struct's tv_sec and tv_nsec range before calling
ptp->info->settime64().

As the man manual of clock_settime() said, if tp.tv_sec is negative or
tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
which include dynamic clocks which handles PTP clock, and the condition is
consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
only check the timespec is valid, but not ensure that the time is
in a valid range, so check it ahead using timespec64_valid_strict()
in pc_clock_settime() and return -EINVAL if not valid.

There are some drivers that use tp->tv_sec and tp->tv_nsec directly to
write registers without validity checks and assume that the higher layer
has checked it, which is dangerous and will benefit from this, such as
hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
and some drivers can remove the checks of itself.


Affected upstream versions: 2.6.39
Fixed upstream versions: 0, 4.19.323, 5.10.228, 5.15.169, 5.4.285, 6.1.114, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 29f085345cde24566efb751f39e5d367c381c584
CVE-2024-50197: kernel: pinctrl: intel: platform: fix error path in device_for_each_child_node()
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

pinctrl: intel: platform: fix error path in device_for_each_child_node()

The device_for_each_child_node() loop requires calls to
fwnode_handle_put() upon early returns to decrement the refcount of
the child node and avoid leaking memory if that error path is triggered.

There is one early returns within that loop in
intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is
missing.

Instead of adding the missing call, the scoped version of the loop can
be used to simplify the code and avoid mistakes in the future if new
early returns are added, as the child node is only used for parsing, and
it is never assigned.


Affected upstream versions: 6.8
Fixed upstream versions: 0, 6.11.5, 6.12
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: be3f7b9f995a6c2ee02767a0319929a2a98adf69
CVE-2024-50199: kernel: mm/swapfile: skip HugeTLB pages for unuse_vma
Component: kernel
Severity: Moderate
CWE: CWE-20 (Improper Input Validation)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

mm/swapfile: skip HugeTLB pages for unuse_vma

I got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The
problem can be reproduced by the following steps:

 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.
 2. Swapout the above anonymous memory.
 3. run swapoff and we will get a bad pud error in kernel message:

  mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)

We can tell that pud_clear_bad is called by pud_none_or_clear_bad in
unuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never
be freed because we lost it from page table.  We can skip HugeTLB pages
for unuse_vma to fix it.


Affected upstream versions: 2.6.36
Fixed upstream versions: 0, 5.10.228, 5.15.169, 5.4.285, 6.1.114, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ba7f982cdb37ff5a7739dec85d7325ea66fc1496
CVE-2024-50201: kernel: drm/radeon: Fix encoder->possible_clones
Component: kernel
Severity: Low
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: Fix encoder->possible_clones

Include the encoder itself in its possible_clones bitmask.
In the past nothing validated that drivers were populating
possible_clones correctly, but that changed in commit
74d2aacbe840 ("drm: Validate encoder->possible_clones").
Looks like radeon never got the memo and is still not
following the rules 100% correctly.

This results in some warnings during driver initialization:
Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)
WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c
...

(cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)


Affected upstream versions: 5.8
Fixed upstream versions: 0, 5.10.228, 5.15.169, 6.1.114, 6.11.5, 6.12, 6.6.58
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: df75c78bfeff99f9b4815c3e79e2b1b1e34fe264
CVE-2024-50208: kernel: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-08T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages

Avoid memory corruption while setting up Level-2 PBL pages for the non MR
resources when num_pages > 256K.

There will be a single PDE page address (contiguous pages in the case of >
PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid
memory access after 256K PBL entries in the PDE.


Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.229, 5.15.170, 6.1.115, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: df6fed0a2a1a5e57f033bca40dc316b18e0d0ce6
CVE-2024-50215: kernel: nvmet-auth: assign dh_key to NULL after kfree_sensitive
Component: kernel
Severity: Moderate
CWE: CWE-415 (Double Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-09T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

nvmet-auth: assign dh_key to NULL after kfree_sensitive

ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup()
for the same controller. So it's better to nullify it after release on
error path in order to avoid double free later in nvmet_destroy_auth().

Found by Linux Verification Center (linuxtesting.org) with Svace.

Statement: This issue is considered to be a moderate impact flaw, as the exploitation for this will need an ADMIN (or ROOT) privilege (PR:H).

Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c94e965f766321641ec38e4eece9ce8884543244
CVE-2024-50216: kernel: xfs: fix finding a last resort AG in xfs_filestream_pick_ag
Component: kernel
Severity: Moderate
CWE: CWE-457 (Use of Uninitialized Variable)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-09T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

xfs: fix finding a last resort AG in xfs_filestream_pick_ag

When the main loop in xfs_filestream_pick_ag fails to find a suitable
AG it tries to just pick the online AG.  But the loop for that uses
args->pag as loop iterator while the later code expects pag to be
set.  Fix this by reusing the max_pag case for this last resort, and
also add a check for impossible case of no AG just to make sure that
the uninitialized pag doesn't even escape in theory.


Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 77ddc732416b017180893cbb2356e9f0a414c575
CVE-2024-50223: kernel: sched/numa: Fix the potential null pointer dereference in task_numa_work()
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-09T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

sched/numa: Fix the potential null pointer dereference in task_numa_work()

When running stress-ng-vm-segv test, we found a null pointer dereference
error in task_numa_work(). Here is the backtrace:

  [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
  ......
  [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se
  ......
  [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--)
  [323676.067115] pc : vma_migratable+0x1c/0xd0
  [323676.067122] lr : task_numa_work+0x1ec/0x4e0
  [323676.067127] sp : ffff8000ada73d20
  [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010
  [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000
  [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000
  [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8
  [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035
  [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8
  [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4
  [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001
  [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000
  [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000
  [323676.067152] Call trace:
  [323676.067153]  vma_migratable+0x1c/0xd0
  [323676.067155]  task_numa_work+0x1ec/0x4e0
  [323676.067157]  task_work_run+0x78/0xd8
  [323676.067161]  do_notify_resume+0x1ec/0x290
  [323676.067163]  el0_svc+0x150/0x160
  [323676.067167]  el0t_64_sync_handler+0xf8/0x128
  [323676.067170]  el0t_64_sync+0x17c/0x180
  [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000)
  [323676.067177] SMP: stopping secondary CPUs
  [323676.070184] Starting crashdump kernel...

stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error
handling function of the system, which tries to cause a SIGSEGV error on
return from unmapping the whole address space of the child process.

Normally this program will not cause kernel crashes. But before the
munmap system call returns to user mode, a potential task_numa_work()
for numa balancing could be added and executed. In this scenario, since the
child process has no vma after munmap, the vma_next() in task_numa_work()
will return a null pointer even if the vma iterator restarts from 0.

Recheck the vma pointer before dereferencing it in task_numa_work().


Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ade91f6e9848b370add44d89c976e070ccb492ef
CVE-2024-50235: kernel: wifi: cfg80211: clear wdev->cqm_config pointer on free
Component: kernel
Severity: Moderate
CWE: CWE-415 (Double Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-11-09T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: clear wdev->cqm_config pointer on free

When we free wdev->cqm_config when unregistering, we also
need to clear out the pointer since the same wdev/netdev
may get re-registered in another network namespace, then
destroyed later, running this code again, which results in
a double-free.

Statement: This issue is considered to be a moderate impact flaw, as the exploitation for this will need an ADMIN (or ROOT) privilege (PR:H).

Affected upstream versions: 6.1.57 < 6.1.116, 6.5.7 < 6.6, 6.6
Fixed upstream versions: 0, 6.1.116, 6.11.7, 6.12, 6.6, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ba392e1355ba74b1d4fa11b85f71ab6ed7ecc058
CVE-2024-50236: kernel: wifi: ath10k: Fix memory leak in management tx
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-09T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath10k: Fix memory leak in management tx

In the current logic, memory is allocated for storing the MSDU context
during management packet TX but this memory is not being freed during
management TX completion. Similar leaks are seen in the management TX
cleanup logic.

Kmemleak reports this problem as below,

unreferenced object 0xffffff80b64ed250 (size 16):
  comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s)
  hex dump (first 16 bytes):
    00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00  .+.......t......
  backtrace:
    [<ffffffe6e7b245dc>] __kmem_cache_alloc_node+0x1e4/0x2d8
    [<ffffffe6e7adde88>] kmalloc_trace+0x48/0x110
    [<ffffffe6bbd765fc>] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]
    [<ffffffe6bbd3eed4>] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]
    [<ffffffe6e78d5974>] process_scheduled_works+0x1ac/0x400
    [<ffffffe6e78d60b8>] worker_thread+0x208/0x328
    [<ffffffe6e78dc890>] kthread+0x100/0x1c0
    [<ffffffe6e78166c0>] ret_from_fork+0x10/0x20

Free the memory during completion and cleanup to fix the leak.

Protect the mgmt_pending_tx idr_remove() operation in
ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to
other instances.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1


Affected upstream versions: 4.19
Fixed upstream versions: 0, 4.19.323, 5.10.229, 5.15.171, 5.4.285, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: eff818238bedb9c2484c251ec46f9f160911cdc0
CVE-2024-50237: kernel: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-11-09T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower

Avoid potentially crashing in the driver because of uninitialized private data


Affected upstream versions: 3.19
Fixed upstream versions: 0, 4.19.323, 5.10.229, 5.15.171, 5.4.285, 6.1.116, 6.11.7, 6.12, 6.6.60
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b0b862aa3dbcd16b3c4715259a825f48ca540088