deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50653
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: atmel-mci: fix return value check of mmc_add_host()

mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
   delete device, but it's not added yet, it will lead a kernel
   crash because of null-ptr-deref in device_del().

So fix this by checking the return value and calling mmc_free_host()
in the error path.
References: https://git.kernel.org/stable/c/00ac0f5f95920f003cd6ece53cdc759549b69118; https://git.kernel.org/stable/c/1925472dec31ec061d57412b3a65a056ea24f340; https://git.kernel.org/stable/c/6bb26abb92f25e582a0976091a10b539fe3796db
CVE: CVE-2022-50654
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix panic due to wrong pageattr of im->image

In the scenario where livepatch and kretfunc coexist, the pageattr of
im->image is rox after arch_prepare_bpf_trampoline in
bpf_trampoline_update, and then modify_fentry or register_fentry returns
-EAGAIN from bpf_tramp_ftrace_ops_func, the BPF_TRAMP_F_ORIG_STACK flag
will be configured, and arch_prepare_bpf_trampoline will be re-executed.

At this time, because the pageattr of im->image is rox,
arch_prepare_bpf_trampoline will read and write im->image, which causes
a fault. as follows:

  insmod livepatch-sample.ko    # samples/livepatch/livepatch-sample.c
  bpftrace -e 'kretfunc:cmdline_proc_show {}'

BUG: unable to handle page fault for address: ffffffffa0206000
PGD 322d067 P4D 322d067 PUD 322e063 PMD 1297e067 PTE d428061
Oops: 0003 [#1] PREEMPT SMP PTI
CPU: 2 PID: 270 Comm: bpftrace Tainted: G            E K    6.1.0 #5
RIP: 0010:arch_prepare_bpf_trampoline+0xed/0x8c0
RSP: 0018:ffffc90001083ad8 EFLAGS: 00010202
RAX: ffffffffa0206000 RBX: [PII_REDACTED] RCX: [PII_REDACTED]
RDX: ffffffffa0206001 RSI: ffffffffa0206000 RDI: [PII_REDACTED]
RBP: ffffc90001083b70 R08: [PII_REDACTED] R09: ffff88800f51b400
R10: 000000002e72c6e5 R11: 00000000d0a15080 R12: ffff8880110a68c8
R13: [PII_REDACTED] R14: ffff88800f51b400 R15: ffffffff814fec10
FS:  00007f87bc0dc780(0000) GS:ffff88803e600000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: ffffffffa0206000 CR3:[PII_REDACTED]b70000 CR4:[PII_REDACTED]0006e0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
<TASK>
 bpf_trampoline_update+0x25a/0x6b0
 __bpf_trampoline_link_prog+0x101/0x240
 bpf_trampoline_link_prog+0x2d/0x50
 bpf_tracing_prog_attach+0x24c/0x530
 bpf_raw_tp_link_attach+0x73/0x1d0
 __sys_bpf+0x100e/0x2570
 __x64_sys_bpf+0x1c/0x30
 do_syscall_64+0x5b/0x80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

With this patch, when modify_fentry or register_fentry returns -EAGAIN
from bpf_tramp_ftrace_ops_func, the pageattr of im->image will be reset
to nx+rw.
References: https://git.kernel.org/stable/c/7f656fff955ccb216c40fa188a24c05fa40985a5; https://git.kernel.org/stable/c/9ed1d9aeef5842ecacb660fce933613b58af1e00; https://git.kernel.org/stable/c/d9d383cbf812a3b4094c089aa5f5d41a3bb4531d
CVE: CVE-2022-50655
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

ppp: associate skb with a device at tx

Syzkaller triggered flow dissector warning with the following:

r0 = openat$ppp(0xffffffffffffff9c, &(0x7f[PII_REDACTED]), 0xc0802, 0x0)
ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))
ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f[PII_REDACTED])={0x2, &(0x7f[PII_REDACTED])=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})
pwritev(r0, &(0x7f[PII_REDACTED])=[{&(0x7f[PII_REDACTED])='\x00!', 0x2}], 0x1, 0x0, 0x0)

[    9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0
[    9.485929]  skb_get_poff+0x53/0xa0
[    9.485937]  bpf_skb_get_pay_offset+0xe/0x20
[    9.485944]  ? ppp_send_frame+0xc2/0x5b0
[    9.485949]  ? _raw_spin_unlock_irqrestore+0x40/0x60
[    9.485958]  ? __ppp_xmit_process+0x7a/0xe0
[    9.485968]  ? ppp_xmit_process+0x5b/0xb0
[    9.485974]  ? ppp_write+0x12a/0x190
[    9.485981]  ? do_iter_write+0x18e/0x2d0
[    9.485987]  ? __import_iovec+0x30/0x130
[    9.485997]  ? do_pwritev+0x1b6/0x240
[    9.486016]  ? trace_hardirqs_on+0x47/0x50
[    9.486023]  ? __x64_sys_pwritev+0x24/0x30
[    9.486026]  ? do_syscall_64+0x3d/0x80
[    9.486031]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd

Flow dissector tries to find skb net namespace either via device
or via socket. Neigher is set in ppp_send_frame, so let's manually
use ppp->dev.
References: https://git.kernel.org/stable/c/148dcbd3af039ae39c3af697a3183008c7995805; https://git.kernel.org/stable/c/18dc946360bfe0de016a59e3cc3ee1f450fceb9d; https://git.kernel.org/stable/c/4b8f3b939266c90f03b7cc7e26a4c28c7b64137b
CVE: CVE-2022-50656
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

nfc: pn533: Clear nfc_target before being used

Fix a slab-out-of-bounds read that occurs in nla_put() called from
nfc_genl_send_target() when target->sensb_res_len, which is duplicated
from an nfc_target in pn533, is too large as the nfc_target is not
properly initialized and retains garbage values. Clear nfc_targets with
memset() before they are used.

Found by a modified version of syzkaller.

BUG: KASAN: slab-out-of-bounds in nla_put
Call Trace:
 memcpy
 nla_put
 nfc_genl_dump_targets
 genl_lock_dumpit
 netlink_dump
 __netlink_dump_start
 genl_family_rcv_msg_dumpit
 genl_rcv_msg
 netlink_rcv_skb
 genl_rcv
 netlink_unicast
 netlink_sendmsg
 sock_sendmsg
 ____sys_sendmsg
 ___sys_sendmsg
 __sys_sendmsg
 do_syscall_64
References: https://git.kernel.org/stable/c/61a7e15d55fae329a245535c3bac494e401005b8; https://git.kernel.org/stable/c/755019e37815a66bb0a23893debbd3dd640ccbd3; https://git.kernel.org/stable/c/8bddef54cbe9ede5ac7478f1e1e968fcfe7e6f03
CVE: CVE-2023-53777
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: kill hooked chains to avoid loops on deduplicated compressed images

After heavily stressing EROFS with several images which include a
hand-crafted image of repeated patterns for more than 46 days, I found
two chains could be linked with each other almost simultaneously and
form a loop so that the entire loop won't be submitted.  As a
consequence, the corresponding file pages will remain locked forever.

It can be _only_ observed on data-deduplicated compressed images.
For example, consider two chains with five pclusters in total:
	Chain 1:  2->3->4->5    -- The tail pcluster is 5;
        Chain 2:  5->1->2       -- The tail pcluster is 2.

Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could link
to Chain 2 at the same time with pcluster 2.

Since hooked chains are all linked locklessly now, I have no idea how
to simply avoid the race.  Instead, let's avoid hooked chains completely
until I could work out a proper way to fix this and end users finally
tell us that it's needed to add it back.

Actually, this optimization can be found with multi-threaded workloads
(especially even more often on deduplicated compressed images), yet I'm
not sure about the overall system impacts of not having this compared
with implementation complexity.
References: https://git.kernel.org/stable/c/10c2b98a40d9044a3e97f4697ca6213bad7e19c2; https://git.kernel.org/stable/c/967c28b23f6c89bb8eef6a046ea88afe0d7c1029; https://git.kernel.org/stable/c/b5b0d52f00e4bacb0ebdf47cd7016b0485fffad2
CVE: CVE-2023-53778
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/qaic: Clean up integer overflow checking in map_user_pages()

The encode_dma() function has some validation on in_trans->size but it
would be more clear to move those checks to find_and_map_user_pages().

The encode_dma() had two checks:

	if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size)
		return -EINVAL;

The in_trans->addr variable is the starting address.  The in_trans->size
variable is the total size of the transfer.  The transfer can occur in
parts and the resources->xferred_dma_size tracks how many bytes we have
already transferred.

This patch introduces a new variable "remaining" which represents the
amount we want to transfer (in_trans->size) minus the amount we have
already transferred (resources->xferred_dma_size).

I have modified the check for if in_trans->size is zero to instead check
if in_trans->size is less than resources->xferred_dma_size.  If we have
already transferred more bytes than in_trans->size then there are negative
bytes remaining which doesn't make sense.  If there are zero bytes
remaining to be copied, just return success.

The check in encode_dma() checked that "addr + size" could not overflow
and barring a driver bug that should work, but it's easier to check if
we do this in parts.  First check that "in_trans->addr +
resources->xferred_dma_size" is safe.  Then check that "xfer_start_addr +
remaining" is safe.

My final concern was that we are dealing with u64 values but on 32bit
systems the kmalloc() function will truncate the sizes to 32 bits.  So
I calculated "total = in_trans->size + offset_in_page(xfer_start_addr);"
and returned -EINVAL if it were >= SIZE_MAX.  This will not affect 64bit
systems.
References: https://git.kernel.org/stable/c/96d3c1cadedb6ae2e8965e19cd12caa244afbd9c; https://git.kernel.org/stable/c/d410a96e5cb8c1ec7049c83f2edcd8bbfaf5d9b3
CVE: CVE-2023-53779
Published: 2025-12-09
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53780
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix FCLK pstate change underflow

[Why]
Currently we set FCLK p-state change
watermark calculated based on dummy
p-state latency when UCLK p-state is
not supported

[How]
Calculate FCLK p-state change watermark
based on on FCLK pstate change latency
in case UCLK p-state is not supported
References: https://git.kernel.org/stable/c/4bdfa48d[PII_REDACTED]8a0bf5c8b8a48dded77b4a; https://git.kernel.org/stable/c/6853d56dba56d1c24db403ff3885c71e18d572c4; https://git.kernel.org/stable/c/972243f973eb0821084e5833d5f7f4ed025f42da
CVE: CVE-2023-53781
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

smc: Fix use-after-free in tcp_write_timer_handler().

With Eric's ref tracker, syzbot finally found a repro for
use-after-free in tcp_write_timer_handler() by kernel TCP
sockets. [0]

If SMC creates a kernel socket in __smc_create(), the kernel
socket is supposed to be freed in smc_clcsock_release() by
calling sock_release() when we close() the parent SMC socket.

However, at the end of smc_clcsock_release(), the kernel
socket's sk_state might not be TCP_CLOSE.  This means that
we have not called inet_csk_destroy_sock() in __tcp_close()
and have not stopped the TCP timers.

The kernel socket's TCP timers can be fired later, so we
need to hold a refcnt for net as we do for MPTCP subflows
in mptcp_subflow_create_socket().

[0]:
leaked reference.
 sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108)
 inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244)
 __sock_create (net/socket.c:1546)
 smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284)
 __sock_create (net/socket.c:1546)
 __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661)
 __x64_sys_socket (net/socket.c:1672)
 do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
==================================================================
BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)
Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091

CPU: 0 PID: 18091 Comm: syzrepro Tainted: G        W          6.3.0-rc4-01174-gb5d54eb5899a #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014
Call Trace:
 <IRQ>
 dump_stack_lvl (lib/dump_stack.c:107)
 print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)
 kasan_report (mm/kasan/report.c:538)
 tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)
 tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643)
 call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)
 __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022)
 run_timer_softirq (kernel/time/timer.c:2037)
 __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572)
 __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650)
 irq_exit_rcu (kernel/softirq.c:664)
 sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))
 </IRQ>
References: https://git.kernel.org/stable/c/1cc41c8acfc1ee30b[PII_REDACTED]db97fa44b0137; https://git.kernel.org/stable/c/9744d2bf[PII_REDACTED]ecba885b7ac282c02eacf
CVE: CVE-2023-53782
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

dccp: Fix out of bounds access in DCCP error handler

There was a previous attempt to fix an out-of-bounds access in the DCCP
error handlers, but that fix assumed that the error handlers only want
to access the first 8 bytes of the DCCP header. Actually, they also look
at the DCCP sequence number, which is stored beyond 8 bytes, so an
explicit pskb_may_pull() is required.
References: https://git.kernel.org/stable/c/177212bf6dc1ff2d13d0409cddc5c9e81feec63d; https://git.kernel.org/stable/c/3533e10272555c422a7d51ebc0ce8c483429f7f2; https://git.kernel.org/stable/c/4b8a938e329ae4eb54b73b0c87b5170607b038a8
CVE: CVE-2023-53783
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-iocost: fix divide by 0 error in calc_lcoefs()

echo max of u64 to cost.model can cause divide by 0 error.

  # echo 8:0 rbps=[PII_REDACTED]709551615 > /sys/fs/cgroup/io.cost.model

  divide error: 0000 [#1] PREEMPT SMP
  RIP: 0010:calc_lcoefs+0x4c/0xc0
  Call Trace:
   <TASK>
   ioc_refresh_params+0x2b3/0x4f0
   ioc_cost_model_write+0x3cb/0x4c0
   ? _copy_from_iter+0x6d/0x6c0
   ? kernfs_fop_write_iter+0xfc/0x270
   cgroup_file_write+0xa0/0x200
   kernfs_fop_write_iter+0x17d/0x270
   vfs_write+0x414/0x620
   ksys_write+0x73/0x160
   __x64_sys_write+0x1e/0x30
   do_syscall_64+0x35/0x80
   entry_SYSCALL_64_after_hwframe+0x63/0xcd

calc_lcoefs() uses the input value of cost.model in DIV_ROUND_UP_ULL,
overflow would happen if bps plus IOC_PAGE_SIZE is greater than
ULLONG_MAX, it can cause divide by 0 error.

Fix the problem by setting basecost
References: https://git.kernel.org/stable/c/3538ade9d8c2ba41088e395de916f2599fadba8f; https://git.kernel.org/stable/c/6e291810fe83a384700eb24a1f714966391ed562; https://git.kernel.org/stable/c/984af1e66b4126cf145153661cc24c213e2ec231
CVE: CVE-2023-53784
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: bridge: dw_hdmi: fix connector access for scdc

Commit 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs") changed the scdc
interface to pick up an i2c adapter from a connector instead. However, in
the case of dw-hdmi, the wrong connector was being used to pass i2c adapter
information, since dw-hdmi's embedded connector structure is only populated
when the bridge attachment callback explicitly asks for it.

drm-meson is handling connector creation, so this won't happen, leading to
a NULL pointer dereference.

Fix it by having scdc functions access dw-hdmi's current connector pointer
instead, which is assigned during the bridge enablement stage.

[narmstrong: moved Fixes tag before first S-o-b and added Reported-by tag]
References: https://git.kernel.org/stable/c/552f79aa9e801ed4f74d6b3221af78042ba4f235; https://git.kernel.org/stable/c/98703e4e061fb8715c7613cd227e32cdfd136b23
CVE: CVE-2023-53785
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7921: don't assume adequate headroom for SDIO headers

mt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and
mt7921_skb_add_usb_sdio_hdr(), both of which blindly assume that
adequate headroom will be available in the passed skb. This assumption
typically is satisfied when the skb was allocated in the net core for
transmission via the mt7921 netdev (although even that is only an
optimization and is not strictly guaranteed), but the assumption is
sometimes not satisfied when the skb originated in the receive path of
another netdev and was passed through to the mt7921, such as by the
bridge layer. Blindly prepending bytes to an skb is always wrong.

This commit introduces a call to skb_cow_head() before the call to
mt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to
ensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can be
pushed onto the skb.

Without this fix, I can trivially cause kernel panics by bridging an
MT7921AU-based USB 802.11ax interface with an Ethernet interface on an
Intel Atom-based x86 system using its onboard RTL8169 PCI Ethernet
adapter and also on an ARM-based Raspberry Pi 1 using its onboard
SMSC9512 USB Ethernet adapter. Note that the panics do not occur in
every system configuration, as they occur only if the receiving netdev
leaves less headroom in its received skbs than the mt7921 needs for its
SDIO headers.

Here is an example stack trace of this panic on Raspberry Pi OS Lite
2023-02-21 running kernel 6.1.24+ [1]:

 skb_panic from skb_push+0x44/0x48
 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common]
 mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb]
 mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76]
 __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76]
 mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76]
 mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common]
 mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76]
 __mt76_worker_fn [mt76] from kthread+0xbc/0xe0
 kthread from ret_from_fork+0x14/0x34

After this fix, bridging the mt7921 interface works fine on both of my
previously problematic systems.

[1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a
References: https://git.kernel.org/stable/c/414c0c04703423b78bc9dea1aa6493334dc61f6e; https://git.kernel.org/stable/c/5c8bbb79c7cbca65534badf360f3b1145759c7bc; https://git.kernel.org/stable/c/98c4d0abf5c478db1ad126ff0c187dbb84c0803c
CVE: CVE-2023-53786
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

dm flakey: fix a crash with invalid table line

This command will crash with NULL pointer dereference:
 dmsetup create flakey --table \
  "0 `blockdev --getsize /dev/ram0` flakey /dev/ram0 0 0 1 2 corrupt_bio_byte 512"

Fix the crash by checking if arg_name is non-NULL before comparing it.
References: https://git.kernel.org/stable/c/12849ed107c0b2869fb775c[PII_REDACTED]9006f07; https://git.kernel.org/stable/c/337b7af273562b73c46ef77a724604ad139ca762; https://git.kernel.org/stable/c/8258d84a7917aeece773716518deadb7ad776cb7
CVE: CVE-2023-53787
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: da9063: fix null pointer deref with partial DT config

When some of the da9063 regulators do not have corresponding DT nodes
a null pointer dereference occurs on boot because such regulators have
no init_data causing the pointers calculated in
da9063_check_xvp_constraints() to be invalid.

Do not dereference them in this case.
References: https://git.kernel.org/stable/c/04a025b17d83d07924e5e32508c72536ab8f42d9; https://git.kernel.org/stable/c/98e2dd5f7a8be5cb2501a897e96910393a49f0ff
CVE: CVE-2023-53788
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda/ca0132: fixup buffer overrun at tuning_ctl_set()

tuning_ctl_set() might have buffer overrun at (X) if it didn't break
from loop by matching (A).

	static int tuning_ctl_set(...)
	{
		for (i = 0; i < TUNING_CTLS_COUNT; i++)
(A)			if (nid == ca0132_tuning_ctls[i].nid)
				break;

		snd_hda_power_up(...);
(X)		dspio_set_param(..., ca0132_tuning_ctls[i].mid, ...);
		snd_hda_power_down(...);                ^

		return 1;
	}

We will get below error by cppcheck

	sound/pci/hda/patch_ca0132.c:4229:2: note: After for loop, i has value 12
	 for (i = 0; i < TUNING_CTLS_COUNT; i++)
	 ^
	sound/pci/hda/patch_ca0132.c:4234:43: note: Array index out of bounds
	 dspio_set_param(codec, ca0132_tuning_ctls[i].mid, 0x20,
	                                           ^
This patch cares non match case.
References: https://git.kernel.org/stable/c/32854bc91ae7debcdefdc7ae881ed83385a04792; https://git.kernel.org/stable/c/[PII_REDACTED]a11aa1f92a97e8a04d95320e347ebd; https://git.kernel.org/stable/c/734a3deb6614e3597e7e9ef7fb6006c593c5ee18
CVE: CVE-2023-53789
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/amd: Improve page fault error reporting

If IOMMU domain for device group is not setup properly then we may hit
IOMMU page fault. Current page fault handler assumes that domain is
always setup and it will hit NULL pointer derefence (see below sample log).

Lets check whether domain is setup or not and log appropriate message.

Sample log:
----------
 amdgpu 0000:00:01.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 6
 BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 2 PID: 56 Comm: irq/24-AMD-Vi Not tainted 6.2.0-rc2+ #89
 Hardware name: xxx
 RIP: 0010:report_iommu_fault+0x11/0x90
 [...]
 Call Trace:
  <TASK>
  amd_iommu_int_thread+0x60c/0x760
  ? __pfx_irq_thread_fn+0x10/0x10
  irq_thread_fn+0x1f/0x60
  irq_thread+0xea/0x1a0
  ? preempt_count_add+0x6a/0xa0
  ? __pfx_irq_thread_dtor+0x10/0x10
  ? __pfx_irq_thread+0x10/0x10
  kthread+0xe9/0x110
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x2c/0x50
  </TASK>

[joro: Edit commit message]
References: https://git.kernel.org/stable/c/446080b353f048b1fddaec1434cb3d27b5de7efe; https://git.kernel.org/stable/c/996d120b4de2b0d6b592bd9fbbe6e244b81ab3cc; https://git.kernel.org/stable/c/be8301e2d5a8b95c04ae8e35d7bfee7b0f03f83a