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

rtc: tps6594: Fix integer overflow on 32bit systems

The problem is this multiply in tps6594_rtc_set_offset()

	tmp = offset * TICKS_PER_HOUR;

The "tmp" variable is an s64 but "offset" is a long in the
(-277774)-277774 range.  On 32bit systems a long can hold numbers up to
approximately two billion.  The number of TICKS_PER_HOUR is really large,
(32768 * 3600) or roughly a hundred million.  When you start multiplying
by a hundred million it doesn't take long to overflow the two billion
mark.

Probably the safest way to fix this is to change the type of
TICKS_PER_HOUR to long long because it's such a large number.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/09c4a610153286cef54d4f0c85398f4e32fc227e; https://git.kernel.org/stable/c/5127f3cbfc78a7b301b[PII_REDACTED]0bec47e0bb3; https://git.kernel.org/stable/c/53b0c7b15accb18d15d95c7fe68f61630ebfd1ca
CVE: CVE-2024-57973
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

rdma/cxgb4: Prevent potential integer overflow on 32bit

The "gl->tot_len" variable is controlled by the user.  It comes from
process_responses().  On 32bit systems, the "gl->tot_len + sizeof(struct
cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an
integer wrapping bug.  Use size_add() to prevent this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/2b759f78b83221f4a1cae3aeb20b500e375f3ee6; https://git.kernel.org/stable/c/4422f452d028850b9cc4fd8f1cf45a8ff91855eb; https://git.kernel.org/stable/c/aeb[PII_REDACTED]11b3579d5c78ad4eb301e3bf1c8
CVE: CVE-2024-57977
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

memcg: fix soft lockup in the OOM process

A soft lockup issue was found in the product with about 56,000 tasks were
in the OOM cgroup, it was traversing them when the soft lockup was
triggered.

watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]
CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G
Hardware name: Huawei Cloud OpenStack Nova, BIOS
RIP: 0010:console_unlock+0x343/0x540
RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13
RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: 00000000ffffffff
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: ffffffffafc71f90 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffffffffafc74bd0
R13: ffffffffaf60a220 R14: [PII_REDACTED] R15: [PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4:[PII_REDACTED]360ee0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 vprintk_emit+0x193/0x280
 printk+0x52/0x6e
 dump_task+0x114/0x130
 mem_cgroup_scan_tasks+0x76/0x100
 dump_header+0x1fe/0x210
 oom_kill_process+0xd1/0x100
 out_of_memory+0x125/0x570
 mem_cgroup_out_of_memory+0xb5/0xd0
 try_charge+0x720/0x770
 mem_cgroup_try_charge+0x86/0x180
 mem_cgroup_try_charge_delay+0x1c/0x40
 do_anonymous_page+0xb5/0x390
 handle_mm_fault+0xc4/0x1f0

This is because thousands of processes are in the OOM cgroup, it takes a
long time to traverse all of them.  As a result, this lead to soft lockup
in the OOM process.

To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks'
function per 1000 iterations.  For global OOM, call
'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0a09d56e1682c951046bf15542b3e9553046c9f6; https://git.kernel.org/stable/c/[PII_REDACTED]4c71f11afefad6e7be9e3876b284f; https://git.kernel.org/stable/c/[PII_REDACTED]1869457d4772bb7df72d7c2bb3d57f
CVE: CVE-2024-57978
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

media: imx-jpeg: Fix potential error pointer dereference in detach_pm()

The proble is on the first line:

	if (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i]))

If jpeg->pd_dev[i] is an error pointer, then passing it to
pm_runtime_suspended() will lead to an Oops.  The other conditions
check for both error pointers and NULL, but it would be more clear to
use the IS_ERR_OR_NULL() check for that.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1378ffec[PII_REDACTED]2b7dbf4fa6a25ee98585d1; https://git.kernel.org/stable/c/1b2af918bb714937a8be6cb637f528585461cd98; https://git.kernel.org/stable/c/6e601a64f7777e2f78c02db1a8b5ba3b7c5e9e31
CVE: CVE-2024-57980
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

media: uvcvideo: Fix double free in error path

If the uvc_status_init() function fails to allocate the int_urb, it will
free the dev->status pointer but doesn't reset the pointer to NULL. This
results in the kfree() call in uvc_status_cleanup() trying to
double-free the memory. Fix it by resetting the dev->status pointer to
NULL after freeing it.

Reviewed by: Ricardo Ribalda <ribalda@chromium.org>
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/3ba8884a56a3eb97c22f0ce0e4dd410d4ca4c277; https://git.kernel.org/stable/c/6c36dcd662ec[PII_REDACTED]660f8533a7cb26be49; https://git.kernel.org/stable/c/87522ef165e5b6de8ef98cc318f3335166a1512c
CVE: CVE-2024-57981
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: Fix NULL pointer dereference on certain command aborts

If a command is queued to the final usable TRB of a ring segment, the
enqueue pointer is advanced to the subsequent link TRB and no further.
If the command is later aborted, when the abort completion is handled
the dequeue pointer is advanced to the first TRB of the next segment.

If no further commands are queued, xhci_handle_stopped_cmd_ring() sees
the ring pointers unequal and assumes that there is a pending command,
so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.

Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell
ring likely is unnecessary too, but it's harmless. Leave it alone.

This is probably Bug 219532, but no confirmation has been received.

The issue has been independently reproduced and confirmed fixed using
a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.
Everything continued working normally after several prevented crashes.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0ce5c0dac768be14afe2426101b568a0f66bfc4d; https://git.kernel.org/stable/c/1e0a19912adb68a4b2b74fd77001c96cd83eb073; https://git.kernel.org/stable/c/4ff18870af793ce2034a6ad746e91d0a3d985b88
CVE: CVE-2024-57982
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

xfrm: state: fix out-of-bounds read during lookup

lookup and resize can run in parallel.

The xfrm_state_hash_generation seqlock ensures a retry, but the hash
functions can observe a hmask value that is too large for the new hlist
array.

rehash does:
  rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..]
  net->xfrm.state_hmask = nhashmask;

While state lookup does:
  h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);
  hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {

This is only safe in case the update to state_bydst is larger than
net->xfrm.xfrm_state_hmask (or if the lookup function gets
serialized via state spinlock again).

Fix this by prefetching state_hmask and the associated pointers.
The xfrm_state_hash_generation seqlock retry will ensure that the pointer
and the hmask will be consistent.

The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,
add lockdep assertions to document that they are only safe for insert
side.

xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.
AFAICS this is an oversight from back when state lookup was converted to
RCU, this lock should be replaced with RCU in a future patch.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/a16871c7832ea6435abb6e0b58289ae7dcb7e4fc; https://git.kernel.org/stable/c/b86dc510308d7a8955f3f47a4fea4bef887653e4; https://git.kernel.org/stable/c/dd4c2a174994238d55ab54da2545543d36f4e0d0
CVE: CVE-2024-57983
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

mailbox: th1520: Fix memory corruption due to incorrect array size

The functions th1520_mbox_suspend_noirq and th1520_mbox_resume_noirq are
intended to save and restore the interrupt mask registers in the MBOX
ICU0. However, the array used to store these registers was incorrectly
sized, leading to memory corruption when accessing all four registers.

This commit corrects the array size to accommodate all four interrupt
mask registers, preventing memory corruption during suspend and resume
operations.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/2cd12c7fba59f30369e8647a2b726c[PII_REDACTED]; https://git.kernel.org/stable/c/db049866943a38bf46a34fa120d526663339d7a5
CVE: CVE-2024-57984
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition

In dw_i3c_common_probe, &master->hj_work is bound with
dw_i3c_hj_work. And dw_i3c_master_irq_handler can call
dw_i3c_master_irq_handle_ibis function to start the work.

If we remove the module which will call dw_i3c_common_remove to
make cleanup, it will free master->base through i3c_master_unregister
while the work mentioned above will be used. The sequence of operations
that may lead to a UAF bug is as follows:

CPU0                                      CPU1

                                     | dw_i3c_hj_work
dw_i3c_common_remove                 |
i3c_master_unregister(&master->base) |
device_unregister(&master->dev)      |
device_release                       |
//free master->base                  |
                                     | i3c_master_do_daa(&master->base)
                                     | //use master->base

Fix it by ensuring that the work is canceled before proceeding with
the cleanup in dw_i3c_common_remove.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/60d2fb033a999bb644f8e8606ff4a1b82de36c6f; https://git.kernel.org/stable/c/9b0063098fcde17cd2894f2c96459b23388507ca; https://git.kernel.org/stable/c/b75439c945b94dd8a2b645355bdb56f948052601
CVE: CVE-2024-57985
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: qcom: scm: Cleanup global '__scm' on probe failures

If SCM driver fails the probe, it should not leave global '__scm'
variable assigned, because external users of this driver will assume the
probe finished successfully.  For example TZMEM parts ('__scm->mempool')
are initialized later in the probe, but users of it (__scm_smc_call())
rely on the '__scm' variable.

This fixes theoretical NULL pointer exception, triggered via introducing
probe deferral in SCM driver with call trace:

  qcom_tzmem_alloc+0x70/0x1ac (P)
  qcom_tzmem_alloc+0x64/0x1ac (L)
  qcom_scm_assign_mem+0x78/0x194
  qcom_rmtfs_mem_probe+0x2d4/0x38c
  platform_probe+0x68/0xc8
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1e76b546e6fca7eb568161f408133904ca6bcf4f; https://git.kernel.org/stable/c/390d3baeba51a126f75c97b90ec28b9384ce4b84; https://git.kernel.org/stable/c/faf1715798fe72b79e4432ce8c6d03ca69765425
CVE: CVE-2024-57986
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections

A report in 2019 by the syzbot fuzzer was found to be connected to two
errors in the HID core associated with Resolution Multipliers.  One of
the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop
in hid_apply_multiplier."), but the other has not been fixed.

This error arises because hid_apply_multipler() assumes that every
Resolution Multiplier control is contained in a Logical Collection,
i.e., there's no way the routine can ever set multiplier_collection to
NULL.  This is in spite of the fact that the function starts with a
big comment saying:

	 * "The Resolution Multiplier control must be contained in the same
	 * Logical Collection as the control(s) to which it is to be applied.
	   ...
	 *  If no Logical Collection is
	 * defined, the Resolution Multiplier is associated with all
	 * controls in the report."
	 * HID Usage Table, v1.12, Section 4.3.1, p30
	 *
	 * Thus, search from the current collection upwards until we find a
	 * logical collection...

The comment and the code overlook the possibility that none of the
collections found may be a Logical Collection.

The fix is to set the multiplier_collection pointer to NULL if the
collection found isn't a Logical Collection.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/05dd7d10675b540b8b7b31035c0a8abb6e6f3b88; https://git.kernel.org/stable/c/3a002e4029230d9a6be89f869b2328b258612f5c; https://git.kernel.org/stable/c/64f2657b579343cf923aa933f08074e6258eb07b
CVE: CVE-2024-57987
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btrtl: check for NULL in btrtl_setup_realtek()

If insert an USB dongle which chip is not maintained in ic_id_table, it
will hit the NULL point accessed. Add a null point check to avoid the
Kernel Oops.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/02f9da874e5e4626f81772eacc[PII_REDACTED]a71; https://git.kernel.org/stable/c/1158ad8e8abb361d4b2aaa010c9af74de20ab82b; https://git.kernel.org/stable/c/3c15082f3567032d196e[PII_REDACTED]332508c2ca
CVE: CVE-2024-57988
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btbcm: Fix NULL deref in btbcm_get_board_name()

devm_kstrdup() can return a NULL pointer on failure,but this
returned value in btbcm_get_board_name() is not checked.
Add NULL check in btbcm_get_board_name(), to handle kernel NULL
pointer dereference error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/74af8b9d0e79deefd2d43e14b84575839a849169; https://git.kernel.org/stable/c/b88655bc6593c6a7fdc1248b212d17e581c4334e; https://git.kernel.org/stable/c/df2f2d9199e61819cca5da0121dfa4d4cb57000f
CVE: CVE-2024-57989
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7925: fix NULL deref check in mt7925_change_vif_links

In mt7925_change_vif_links() devm_kzalloc() may return NULL but this
returned value is not checked.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/2f709fe755c16b811ba7339ae4c3ee2c72323d3d; https://git.kernel.org/stable/c/5872530c[PII_REDACTED]223a2c2ea85642bf2f8875; https://git.kernel.org/stable/c/5cd0bd815c8a48862a296df9b30e0ea0da14acd3
CVE: CVE-2024-57990
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7925: fix off by one in mt7925_load_clc()

This comparison should be >= instead of > to prevent an out of bounds
read and write.
CVSS Score: 7.8 (HIGH)
CWE: CWE-193, CWE-193
References: https://git.kernel.org/stable/c/08fa656c91fd5fdf47ba393795b9c0d1e97539ed; https://git.kernel.org/stable/c/2d1628d32300e4f67ac0b7409cbfa7b912a8fe9d; https://git.kernel.org/stable/c/d03b8fe1b518fc2ea2d82588e905f56d80cd64b2
CVE: CVE-2024-57991
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: chan: fix soft lockup in rtw89_entity_recalc_mgnt_roles()

During rtw89_entity_recalc_mgnt_roles(), there is a normalizing process
which will re-order the list if an entry with target pattern is found.
And once one is found, should have aborted the list_for_each_entry. But,
`break` just aborted the inner for-loop. The outer list_for_each_entry
still continues. Normally, only the first entry will match the target
pattern, and the re-ordering will change nothing, so there won't be
soft lockup. However, in some special cases, soft lockup would happen.

Fix it by `goto fill` to break from the list_for_each_entry.

The following is a sample of kernel log for this problem.

watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [wpa_supplicant:2055]
[...]
RIP: 0010:rtw89_entity_recalc ([...] chan.c:392 chan.c:479) rtw89_core
[...]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/01d2d34e9fcc9897081c3c16a666f793c8a38c58; https://git.kernel.org/stable/c/223ba95fdcd3c6090e2bd51dce66abb6dd4f9df9; https://git.kernel.org/stable/c/e4790b3e314a4814f1680a5dc552031fb199b878
CVE: CVE-2024-57992
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: wilc1000: unregister wiphy only if it has been registered

There is a specific error path in probe functions in wilc drivers (both
sdio and spi) which can lead to kernel panic, as this one for example
when using SPI:

Unable to handle kernel paging request at virtual address 9f000000 when read
[9f000000] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in: wilc1000_spi(+) crc_itu_t crc7 wilc1000 cfg80211 bluetooth ecdh_generic ecc
CPU: 0 UID: 0 PID: 106 Comm: modprobe Not tainted 6.13.0-rc3+ #22
Hardware name: Atmel SAMA5
PC is at wiphy_unregister+0x244/0xc40 [cfg80211]
LR is at wiphy_unregister+0x1c0/0xc40 [cfg80211]
[...]
 wiphy_unregister [cfg80211] from wilc_netdev_cleanup+0x380/0x494 [wilc1000]
 wilc_netdev_cleanup [wilc1000] from wilc_bus_probe+0x360/0x834 [wilc1000_spi]
 wilc_bus_probe [wilc1000_spi] from spi_probe+0x15c/0x1d4
 spi_probe from really_probe+0x270/0xb2c
 really_probe from __driver_probe_device+0x1dc/0x4e8
 __driver_probe_device from driver_probe_device+0x5c/0x140
 driver_probe_device from __driver_attach+0x220/0x540
 __driver_attach from bus_for_each_dev+0x13c/0x1a8
 bus_for_each_dev from bus_add_driver+0x2a0/0x6a4
 bus_add_driver from driver_register+0x27c/0x51c
 driver_register from do_one_initcall+0xf8/0x564
 do_one_initcall from do_init_module+0x2e4/0x82c
 do_init_module from load_module+0x59a0/0x70c4
 load_module from init_module_from_file+0x100/0x148
 init_module_from_file from sys_finit_module+0x2fc/0x924
 sys_finit_module from ret_fast_syscall+0x0/0x1c

The issue can easily be reproduced, for example by not wiring correctly
a wilc device through SPI (and so, make it unresponsive to early SPI
commands). It is due to a recent change decoupling wiphy allocation from
wiphy registration, however wilc_netdev_cleanup has not been updated
accordingly, letting it possibly call wiphy unregister on a wiphy which
has never been registered.

Fix this crash by moving wiphy_unregister/wiphy_free out of
wilc_netdev_cleanup, and by adjusting error paths in both drivers
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1be94490b6b8a06ff14cd23fda8714e6ec37cdfb; https://git.kernel.org/stable/c/c7115b8229f3e6cdfae43b1cdd180f5b6c67cd70
CVE: CVE-2024-57993
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check

syzbot has found a type mismatch between a USB pipe and the transfer
endpoint, which is triggered by the hid-thrustmaster driver[1].
There is a number of similar, already fixed issues [2].
In this case as in others, implementing check for endpoint type fixes the issue.

[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470
[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/220883fba32549a34f0734e4859d07f4dcd56992; https://git.kernel.org/stable/c/50420d7c79c37a3efe4010ff9b1bb14bc61ebccf; https://git.kernel.org/stable/c/816e84602900f7f951458d743fa12769635ebfd5
CVE: CVE-2024-57994
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()

Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()
to increase test coverage.

syzbot found a splat caused by hard irq blocking in
ptr_ring_resize_multiple() [1]

As current users of ptr_ring_resize_multiple() do not require
hard irqs being masked, replace it to only block BH.

Rename helpers to better reflect they are safe against BH only.

- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
- skb_array_resize_multiple() to skb_array_resize_multiple_bh()

[1]

WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]
WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780
Modules linked in:
CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]
RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780
Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85
RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083
RAX: ffffffff8997e523 RBX: [PII_REDACTED] RCX: [PII_REDACTED]
RDX: ffffc9000fbd0000 RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: [PII_REDACTED] R08: ffffffff8997df2c R09: 1ffffd40003a000d
R10: dffffc[PII_REDACTED] R11: fffff940003a000e R12: ffffea0001d00040
R13: ffff88802e8a4000 R14: dffffc[PII_REDACTED] R15: 00000000ffffffff
FS:  00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007fa15a0d4b72 CR3:[PII_REDACTED]1b0000 CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 tun_ptr_free drivers/net/tun.c:617 [inline]
 __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline]
 ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline]
 tun_queue_resize drivers/net/tun.c:3694 [inline]
 tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714
 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]
 call_netdevice_notifiers net/core/dev.c:2046 [inline]
 dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024
 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923
 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201
 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647
 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3257dac521d0ac6653108c755141dce634bb8ff2; https://git.kernel.org/stable/c/572777a258c048e0d0fb3a0c47430eadcefe80c0; https://git.kernel.org/stable/c/a126061c80d5efb4baef4bcf346094139cd81df6
CVE: CVE-2024-57995
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix read pointer after free in ath12k_mac_assign_vif_to_vdev()

In ath12k_mac_assign_vif_to_vdev(), if arvif is created on a different
radio, it gets deleted from that radio through a call to
ath12k_mac_unassign_link_vif(). This action frees the arvif pointer.
Subsequently, there is a check involving arvif, which will result in a
read-after-free scenario.

Fix this by moving this check after arvif is again assigned via call to
ath12k_mac_assign_link_vif().

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/57100b87c77818cb0d582a92e5cb32fff85c757d; https://git.kernel.org/stable/c/5a10971c7645a95f5d5dc23c26fbac4bf61801d0; https://git.kernel.org/stable/c/f3a95a312419e4f1e992525917da9dbcd247038f