deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-22110
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnetlink_queue: Initialize ctx to avoid memory allocation error

It is possible that ctx in nfqnl_build_packet_message() could be used
before it is properly initialize, which is only initialized
by nfqnl_get_sk_secctx().

This patch corrects this problem by initializing the lsmctx to a safe
value when it is declared.

This is similar to the commit 35fcac7a7c25
("audit: Initialize lsmctx to avoid memory allocation error").
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/778b09d91baafb13408470c721d034d6515cfa5a; https://git.kernel.org/stable/c/ddbf7e1d82a1d0c1d3425931a6cb1b83f8454759
CVE: CVE-2025-22112
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

eth: bnxt: fix out-of-range access of vnic_info array

The bnxt_queue_{start | stop}() access vnic_info as much as allocated,
which indicates bp->nr_vnics.
So, it should not reach bp->vnic_info[bp->nr_vnics].
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/919f9f497dbcee75d487400e8f9815b74a6a37df; https://git.kernel.org/stable/c/b1e081d331ab3a0dea25425f2b6ddeb365fc9d22; https://git.kernel.org/stable/c/e1724f07693439deaa413ebc2a2640325cf247f5
CVE: CVE-2025-22113
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid journaling sb update on error if journal is destroying

Presently we always BUG_ON if trying to start a transaction on a journal marked
with JBD2_UNMOUNT, since this should never happen. However, while ltp running
stress tests, it was observed that in case of some error handling paths, it is
possible for update_super_work to start a transaction after the journal is
destroyed eg:

(umount)
ext4_kill_sb
  kill_block_super
    generic_shutdown_super
      sync_filesystem /* commits all txns */
      evict_inodes
        /* might start a new txn */
      ext4_put_super
	flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */
        jbd2_journal_destroy
          journal_kill_thread
            journal->j_flags |= JBD2_UNMOUNT;
          jbd2_journal_commit_transaction
            jbd2_journal_get_descriptor_buffer
              jbd2_journal_bmap
                ext4_journal_bmap
                  ext4_map_blocks
                    ...
                    ext4_inode_error
                      ext4_handle_error
                        schedule_work(&sbi->s_sb_upd_work)

                                               /* work queue kicks in */
                                               update_super_work
                                                 jbd2_journal_start
                                                   start_this_handle
                                                     BUG_ON(journal->j_flags &
                                                            JBD2_UNMOUNT)

Hence, introduce a new mount flag to indicate journal is destroying and only do
a journaled (and deferred) update of sb if this flag is not set. Otherwise, just
fallback to an un-journaled commit.

Further, in the journal destroy path, we have the following sequence:

  1. Set mount flag indicating journal is destroying
  2. force a commit and wait for it
  3. flush pending sb updates

This sequence is important as it ensures that, after this point, there is no sb
update that might be journaled so it is safe to update the sb outside the
journal. (To avoid race discussed in 2d01ddc86606)

Also, we don't need a similar check in ext4_grp_locked_error since it is only
called from mballoc and AFAICT it would be always valid to schedule work here.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/ce2f26e73783b4a7c46a86e3af5b5c8de0971790; https://git.kernel.org/stable/c/db05767b5bc307143d99fe2afd8c43af58d2ebef; https://git.kernel.org/stable/c/eddca44ddf810e27f0c96913aa3cc92ebd679ddb
CVE: CVE-2025-22114
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: don't clobber ret in btrfs_validate_super()

Commit 2a9bb78cfd36 ("btrfs: validate system chunk array at
btrfs_validate_super()") introduces a call to validate_sys_chunk_array()
in btrfs_validate_super(), which clobbers the value of ret set earlier.
This has the effect of negating the validity checks done earlier, making
it so btrfs could potentially try to mount invalid filesystems.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/9db9c7dd5b4e1d3205137a[PII_REDACTED]82c37716; https://git.kernel.org/stable/c/ef6800a2015e706e9852a5ec15263fec9990d012
CVE: CVE-2025-22116
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

idpf: check error for register_netdev() on init

Current init logic ignores the error code from register_netdev(),
which will cause WARN_ON() on attempt to unregister it, if there was one,
and there is no info for the user that the creation of the netdev failed.

WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10
...
[ 3707.563641]  unregister_netdev+0x1c/0x30
[ 3707.563656]  idpf_vport_dealloc+0x5cf/0xce0 [idpf]
[ 3707.563684]  idpf_deinit_task+0xef/0x160 [idpf]
[ 3707.563712]  idpf_vc_core_deinit+0x84/0x320 [idpf]
[ 3707.563739]  idpf_remove+0xbf/0x780 [idpf]
[ 3707.563769]  pci_device_remove+0xab/0x1e0
[ 3707.563786]  device_release_driver_internal+0x371/0x530
[ 3707.563803]  driver_detach+0xbf/0x180
[ 3707.563816]  bus_remove_driver+0x11b/0x2a0
[ 3707.563829]  pci_unregister_driver+0x2a/0x250

Introduce an error check and log the vport number and error code.
On removal make sure to check VPORT_REG_NETDEV flag prior to calling
unregister and free on the netdev.

Add local variables for idx, vport_config and netdev for readability.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1ca996324eacab8fdb7c8ac231eebe5ef0c3c454; https://git.kernel.org/stable/c/680811c67906191b237bbafe7dabbbad64649b39; https://git.kernel.org/stable/c/89768e33752211b2240ec4c34138170c95f11f97
CVE: CVE-2025-22117
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: fix using untrusted value of pkt_len in ice_vc_fdir_parse_raw()

Fix using the untrusted value of proto->raw.pkt_len in function
ice_vc_fdir_parse_raw() by verifying if it does not exceed the
VIRTCHNL_MAX_SIZE_RAW_PACKET value.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1388dd564183a5a18ec4a[PII_REDACTED]36b5653c5; https://git.kernel.org/stable/c/362f704ba73a359db9cded567e891d9a8f081875; https://git.kernel.org/stable/c/363377af2c9e874fbba3a199408f8ec7b37906f7
CVE: CVE-2025-22118
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: validate queue quanta parameters to prevent OOB access

Add queue wraparound prevention in quanta configuration.
Ensure end_qid does not overflow by validating start_qid and num_queues.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/4161cf3f4c11006507f4e02bedc048a215a4b81a; https://git.kernel.org/stable/c/e2f7d3f7331b92cb820da23e8c45133305da1e63
CVE: CVE-2025-22120
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: goto right label 'out_mmap_sem' in ext4_setattr()

Otherwise, if ext4_inode_attach_jinode() fails, a hung task will
happen because filemap_invalidate_unlock() isn't called to unlock
mapping->invalidate_lock. Like this:

EXT4-fs error (device sda) in ext4_setattr:5557: Out of memory
INFO: task fsstress:374 blocked for more than 122 seconds.
      Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:fsstress state:D stack:0     pid:374   tgid:374   ppid:373
                                  task_flags:0x440140 flags:0x00000000
Call Trace:
 <TASK>
 __schedule+0x2c9/0x7f0
 schedule+0x27/0xa0
 schedule_preempt_disabled+0x15/0x30
 rwsem_down_read_slowpath+0x278/0x4c0
 down_read+0x59/0xb0
 page_cache_ra_unbounded+0x65/0x1b0
 filemap_get_pages+0x124/0x3e0
 filemap_read+0x114/0x3d0
 vfs_read+0x297/0x360
 ksys_read+0x6c/0xe0
 do_syscall_64+0x4b/0x110
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/32d872e3905746ff[PII_REDACTED]cb00f946b97d8a; https://git.kernel.org/stable/c/45314999f950321a341033ae8f9ac12dce40669b; https://git.kernel.org/stable/c/551667f99bcf04fa58594d7d19aef73c861a1200
CVE: CVE-2025-22121
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()

There's issue as follows:
BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790
Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172

CPU: 3 PID: 15172 Comm: syz-executor.0
Call Trace:
 __dump_stack lib/dump_stack.c:82 [inline]
 dump_stack+0xbe/0xfd lib/dump_stack.c:123
 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400
 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560
 kasan_report+0x3a/0x50 mm/kasan/report.c:585
 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137
 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896
 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323
 evict+0x39f/0x880 fs/inode.c:622
 iput_final fs/inode.c:1746 [inline]
 iput fs/inode.c:1772 [inline]
 iput+0x525/0x6c0 fs/inode.c:1758
 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline]
 ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300
 mount_bdev+0x355/0x410 fs/super.c:1446
 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611
 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576
 do_new_mount fs/namespace.c:2983 [inline]
 path_mount+0x119a/0x1ad0 fs/namespace.c:3316
 do_mount+0xfc/0x110 fs/namespace.c:3329
 __do_sys_mount fs/namespace.c:3540 [inline]
 __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1

Memory state around the buggy address:
 ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Above issue happens as ext4_xattr_delete_inode() isn't check xattr
is valid if xattr is in inode.
To solve above issue call xattr_check_inode() check if xattr if valid
in inode. In fact, we can directly verify in ext4_iget_extra_inode(),
so that there is no divergent verification.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/098927a13fd918bd7c64c2de905350a1ad7b4a3a; https://git.kernel.org/stable/c/0c8fbb6ffb3c8f5164572ca88e4ccb6cd6a41ca8; https://git.kernel.org/stable/c/27202452b0bc942fdc3db72a44c4dcdab96d5b56
CVE: CVE-2025-22122
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

block: fix adding folio to bio

>4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage
is supported, then 'offset' of folio can't be held in 'unsigned int',
cause warning in bio_add_folio_nofail() and IO failure.

Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't
be overflow, and folio can be added to bio successfully.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0c60158ff14df04c92792dd9b1809372b095040f; https://git.kernel.org/stable/c/26064d3e2b4d9a14df1072980e558c636fb023ea; https://git.kernel.org/stable/c/b96e0af1b1c99cb7e6188b6fa4963a4e47beb01e
CVE: CVE-2025-22123
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid accessing uninitialized curseg

syzbot reports a f2fs bug as below:

F2FS-fs (loop3): Stopped filesystem due to reason: 7
kworker/u8:7: attempt to access beyond end of device
BUG: unable to handle page fault for address: ffffed1604ea3dfa
RIP: 0010:get_ckpt_valid_blocks fs/f2fs/segment.h:361 [inline]
RIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline]
RIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline]
RIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline]
RIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649
 <TASK>
 f2fs_is_checkpoint_ready fs/f2fs/segment.h:671 [inline]
 f2fs_write_inode+0x425/0x540 fs/f2fs/inode.c:791
 write_inode fs/fs-writeback.c:1525 [inline]
 __writeback_single_inode+0x708/0x10d0 fs/fs-writeback.c:1745
 writeback_sb_inodes+0x820/0x1360 fs/fs-writeback.c:1976
 wb_writeback+0x413/0xb80 fs/fs-writeback.c:2156
 wb_do_writeback fs/fs-writeback.c:2303 [inline]
 wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343
 process_one_work kernel/workqueue.c:3236 [inline]
 process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317
 worker_thread+0x870/0xd30 kernel/workqueue.c:3398
 kthread+0x7a9/0x920 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Commit 8b10d3653735 ("f2fs: introduce FAULT_NO_SEGMENT") allows to trigger
no free segment fault in allocator, then it will update curseg->segno to
NULL_SEGNO, though, CP_ERROR_FLAG has been set, f2fs_write_inode() missed
to check the flag, and access invalid curseg->segno directly in below call
path, then resulting in panic:

- f2fs_write_inode
 - f2fs_is_checkpoint_ready
  - has_enough_free_secs
   - has_not_enough_free_secs
    - __get_secs_required
     - has_curseg_enough_space
      - get_ckpt_valid_blocks
      : access invalid curseg->segno

To avoid this issue, let's:
- check CP_ERROR_FLAG flag in prior to f2fs_is_checkpoint_ready() in
f2fs_write_inode().
- in has_curseg_enough_space(), save curseg->segno into a temp variable,
and verify its validation before use.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/7f90e5d423cd2d4c74b2abb527872f335108637f; https://git.kernel.org/stable/c/986c50f6bca109c6cf362b4e2babcb85aba958f6; https://git.kernel.org/stable/c/bf49527089ec1ba894c6e587affabbfb2329f52e
CVE: CVE-2025-22124
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb

In clustermd, separate write-intent-bitmaps are used for each cluster
node:

0                    4k                     8k                    12k
-------------------------------------------------------------------
| idle                | md super            | bm super [0] + bits |
| bm bits[0, contd]   | bm super[1] + bits  | bm bits[1, contd]   |
| bm super[2] + bits  | bm bits [2, contd]  | bm super[3] + bits  |
| bm bits [3, contd]  |                     |                     |

So in node 1, pg_index in __write_sb_page() could equal to
bitmap->storage.file_pages. Then bitmap_limit will be calculated to
0. md_super_write() will be called with 0 size.
That means the first 4k sb area of node 1 will never be updated
through filemap_write_page().
This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize.

Here use (pg_index % bitmap->storage.file_pages) to make calculation
of bitmap_limit correct.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/60196f92bbc7901eb5cfa5d456651b87ea50a4a3; https://git.kernel.org/stable/c/6130825f34d41718c98a9b1504a79a23e379701e; https://git.kernel.org/stable/c/bc3a[PII_REDACTED]359527763d7e1fcf26554c7cb1
CVE: CVE-2025-22125
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid1,raid10: don't ignore IO flags

If blk-wbt is enabled by default, it's found that raid write performance
is quite bad because all IO are throttled by wbt of underlying disks,
due to flag REQ_IDLE is ignored. And turns out this behaviour exist since
blk-wbt is introduced.

Other than REQ_IDLE, other flags should not be ignored as well, for
example REQ_META can be set for filesystems, clearing it can cause priority
reverse problems; And REQ_NOWAIT should not be cleared as well, because
io will wait instead of failing directly in underlying disks.

Fix those problems by keep IO flags from master bio.

Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/10f4ff4baeb6951cf[PII_REDACTED]8827b6852d501; https://git.kernel.org/stable/c/73506e581c0b1814cdfd2229d589f30751d7de26; https://git.kernel.org/stable/c/8a0adf3d778c4a0893c6d34a9e1b0082a6f1c495
CVE: CVE-2025-22126
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

md: fix mddev uaf while iterating all_mddevs list

While iterating all_mddevs list from md_notify_reboot() and md_exit(),
list_for_each_entry_safe is used, and this can race with deletint the
next mddev, causing UAF:

t1:
spin_lock
//list_for_each_entry_safe(mddev, n, ...)
 mddev_get(mddev1)
 // assume mddev2 is the next entry
 spin_unlock
            t2:
            //remove mddev2
            ...
            mddev_free
            spin_lock
            list_del
            spin_unlock
            kfree(mddev2)
 mddev_put(mddev1)
 spin_lock
 //continue dereference mddev2->all_mddevs

The old helper for_each_mddev() actually grab the reference of mddev2
while holding the lock, to prevent from being freed. This problem can be
fixed the same way, however, the code will be complex.

Hence switch to use list_for_each_entry, in this case mddev_put() can free
the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor
out a helper mddev_put_locked() to fix this problem.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5462544ccbad3fc938a71b01fa5bd3a0dc2b750a; https://git.kernel.org/stable/c/[PII_REDACTED]c3a48ff049b6c5df5f50c8728284fa; https://git.kernel.org/stable/c/ca9f84de76723b358dfc0606668efdca54afc2e5
CVE: CVE-2025-22127
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix potential deadloop in prepare_compress_overwrite()

Jan Prusakowski reported a kernel hang issue as below:

When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I
encountered a problem in generic/475 test where fsstress process
gets blocked in __f2fs_write_data_pages() and the test hangs.
The options I used are:

MKFS_OPTIONS  -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc

INFO: task kworker/u8:0:11 blocked for more than 122 seconds.
      Not tainted 6.14.0-rc3-xfstests-lockdep #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/u8:0    state:D stack:0     pid:11    tgid:11    ppid:2      task_flags:0x4208160 flags:0x00004000
Workqueue: writeback wb_workfn (flush-253:0)
Call Trace:
 <TASK>
 __schedule+0x309/0x8e0
 schedule+0x3a/0x100
 schedule_preempt_disabled+0x15/0x30
 __mutex_lock+0x59a/0xdb0
 __f2fs_write_data_pages+0x3ac/0x400
 do_writepages+0xe8/0x290
 __writeback_single_inode+0x5c/0x360
 writeback_sb_inodes+0x22f/0x570
 wb_writeback+0xb0/0x410
 wb_do_writeback+0x47/0x2f0
 wb_workfn+0x5a/0x1c0
 process_one_work+0x223/0x5b0
 worker_thread+0x1d5/0x3c0
 kthread+0xfd/0x230
 ret_from_fork+0x31/0x50
 ret_from_fork_asm+0x1a/0x30
 </TASK>

The root cause is: once generic/475 starts toload error table to dm
device, f2fs_prepare_compress_overwrite() will loop reading compressed
cluster pages due to IO error, meanwhile it has held .writepages lock,
it can block all other writeback tasks.

Let's fix this issue w/ below changes:
- add f2fs_handle_page_eio() in prepare_compress_overwrite() to
detect IO error.
- detect cp_error earler in f2fs_read_multi_pages().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3147ee567dd9004a49826ddeaf0a4b12865d4409; https://git.kernel.org/stable/c/7215cf8ef54bdc9082dffac4662416d54961e258
CVE: CVE-2025-22128
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path

If a shared IRQ is used by the driver due to platform limitation, then the
IRQ affinity hint is set right after the allocation of IRQ vectors in
ath12k_pci_msi_alloc(). This does no harm unless one of the functions
requesting the IRQ fails and attempt to free the IRQ.

This may end up with a warning from the IRQ core that is expecting the
affinity hint to be cleared before freeing the IRQ:

kernel/irq/manage.c:

	/* make sure affinity_hint is cleaned up */
	if (WARN_ON_ONCE(desc->affinity_hint))
		desc->affinity_hint = NULL;

So to fix this issue, clear the IRQ affinity hint before calling
ath12k_pci_free_irq() in the error path. The affinity will be cleared once
again further down the error path due to code organization, but that does
no harm.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/35b33ba76765ce9e72949d957f3cf1feafd2955c; https://git.kernel.org/stable/c/a69a594794fcad96d4cfce12aab6c5014a12b4c8; https://git.kernel.org/stable/c/b43b1e2c52db77c872bd60d30cdcc72c47df70c7
CVE: CVE-2025-23129
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path

If a shared IRQ is used by the driver due to platform limitation, then the
IRQ affinity hint is set right after the allocation of IRQ vectors in
ath11k_pci_alloc_msi(). This does no harm unless one of the functions
requesting the IRQ fails and attempt to free the IRQ. This results in the
below warning:

WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c
Call trace:
 free_irq+0x278/0x29c
 ath11k_pcic_free_irq+0x70/0x10c [ath11k]
 ath11k_pci_probe+0x800/0x820 [ath11k_pci]
 local_pci_probe+0x40/0xbc

The warning is due to not clearing the affinity hint before freeing the
IRQs.

So to fix this issue, clear the IRQ affinity hint before calling
ath11k_pcic_free_irq() in the error path. The affinity will be cleared once
again further down the error path due to code organization, but that does
no harm.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3fc42cfcc6e336f25dee79b34e57c4a63cd652a5; https://git.kernel.org/stable/c/68410c5bd381a81bcc92b808e7dc4e6b9ed25d11; https://git.kernel.org/stable/c/80dc5a2ce5b75d648e08549617f5c555d07ae43c