deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49199
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/nldev: Prevent underflow in nldev_stat_set_counter_dynamic_doit()

This code checks "index" for an upper bound but it does not check for
negatives.  Change the type to unsigned to prevent underflows.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191
References: https://git.kernel.org/stable/c/2a495ef04d5f42e6f00eb2bec1ee9075e3d5a771; https://git.kernel.org/stable/c/87e0eacb176f9500c2063d140c0a1d7fa51ab8a5; https://git.kernel.org/stable/c/f6dd8669b8299a3a536cd92a7069152a7704da1d
CVE: CVE-2022-49200
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btmtksdio: Fix kernel oops in btmtksdio_interrupt

Fix the following kernel oops in btmtksdio_interrrupt

[   14.339134]  btmtksdio_interrupt+0x28/0x54
[   14.339139]  process_sdio_pending_irqs+0x68/0x1a0
[   14.339144]  sdio_irq_work+0x40/0x70
[   14.339154]  process_one_work+0x184/0x39c
[   14.339160]  worker_thread+0x228/0x3e8
[   14.339168]  kthread+0x148/0x3ac
[   14.339176]  ret_from_fork+0x10/0x30

That happened because hdev->power_on is already called before
sdio_set_drvdata which btmtksdio_interrupt handler relies on is not
properly set up.

The details are shown as the below: hci_register_dev would run
queue_work(hdev->req_workqueue, &hdev->power_on) as WQ_HIGHPRI
workqueue_struct to complete the power-on sequeunce and thus hci_power_on
may run before sdio_set_drvdata is done in btmtksdio_probe.

The hci_dev_do_open in hci_power_on would initialize the device and enable
the interrupt and thus it is possible that btmtksdio_interrupt is being
called right before sdio_set_drvdata is filled out.

When btmtksdio_interrupt is being called and sdio_set_drvdata is not filled
, the kernel oops is going to happen because btmtksdio_interrupt access an
uninitialized pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/4d3d1f2c35a19988d3c5f0ee86038b525e830840; https://git.kernel.org/stable/c/6d7be5afbb41c918d2f12f857f8c7efa50500be2; https://git.kernel.org/stable/c/70a6cf749d9ff9f[PII_REDACTED]22e5343199bc267
CVE: CVE-2022-49202
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_uart: add missing NULL check in h5_enqueue

Syzbot hit general protection fault in __pm_runtime_resume(). The problem
was in missing NULL check.

hu->serdev can be NULL and we should not blindly pass &serdev->dev
somewhere, since it will cause GPF.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/32cb08e958696908a9aad5e49a78d74f7e32fffb; https://git.kernel.org/stable/c/[PII_REDACTED]d290367d60ae22fcdfc565e61d42ab; https://git.kernel.org/stable/c/8a3896c30f542439d36303183dc96f65df8cc528
CVE: CVE-2022-49203
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix double free during GPU reset on DC streams

[Why]
The issue only occurs during the GPU reset code path.

We first backup the current state prior to commiting 0 streams
internally from DM to DC. This state backup contains valid link
encoder assignments.

DC will clear the link encoder assignments as part of current state
(but not the backup, since it was a copied before the commit) and
free the extra stream reference it held.

DC requires that the link encoder assignments remain cleared/invalid
prior to commiting. Since the backup still has valid assignments we
call the interface post reset to clear them. This routine also
releases the extra reference that the link encoder interface held -
resulting in a double free (and eventually a NULL pointer dereference).

[How]
We'll have to do a full DC commit anyway after GPU reset because
the stream count previously went to 0.

We don't need to retain the assignment that we had backed up, so
just copy off of the now clean current state assignment after the
reset has occcurred with the new link_enc_cfg_copy() interface.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-415, CWE-415
References: https://git.kernel.org/stable/c/32685b32d825ca08c5dec826477332df886c4743; https://git.kernel.org/stable/c/bbfcdd6289ba6f00f0cd7d496946dce9f6c600ac
CVE: CVE-2022-49204
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix more uncharged while msg has more_data

In tcp_bpf_send_verdict(), if msg has more data after
tcp_bpf_sendmsg_redir():

tcp_bpf_send_verdict()
 tosend = msg->sg.size  //msg->sg.size = 22220
 case __SK_REDIRECT:
  sk_msg_return()  //uncharged msg->sg.size(22220) sk->sk_forward_alloc
  tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000
 goto more_data;
 tosend = msg->sg.size  //msg->sg.size = 11000
 case __SK_REDIRECT:
  sk_msg_return()  //uncharged msg->sg.size(11000) to sk->sk_forward_alloc

The msg->sg.size(11000) has been uncharged twice, to fix we can charge the
remaining msg->sg.size before goto more data.

This issue can cause the following info:
WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
 <TASK>
 inet_csk_destroy_sock+0x55/0x110
 __tcp_close+0x279/0x470
 tcp_close+0x1f/0x60
 inet_release+0x3f/0x80
 __sock_release+0x3d/0xb0
 sock_close+0x11/0x20
 __fput+0x92/0x250
 task_work_run+0x6a/0xa0
 do_exit+0x33b/0xb60
 do_group_exit+0x2f/0xa0
 get_signal+0xb6/0x950
 arch_do_signal_or_restart+0xac/0x2a0
 ? vfs_write+0x237/0x290
 exit_to_user_mode_prepare+0xa9/0x200
 syscall_exit_to_user_mode+0x12/0x30
 do_syscall_64+0x46/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
 </TASK>

WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
 <TASK>
 __sk_destruct+0x24/0x1f0
 sk_psock_destroy+0x19b/0x1c0
 process_one_work+0x1b3/0x3c0
 worker_thread+0x30/0x350
 ? process_one_work+0x3c0/0x3c0
 kthread+0xe6/0x110
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30
 </TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/168ff181f5b6e7fce684c98a30d35da1dbf8f82a; https://git.kernel.org/stable/c/244ce90c8d0bd10ebf957da02c6f3fcd5d920bdf; https://git.kernel.org/stable/c/7b812a369e6416ab06d83cdd39d8e3f752781dd0
CVE: CVE-2022-49205
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix double uncharge the mem of sk_msg

If tcp_bpf_sendmsg is running during a tear down operation, psock may be
freed.

tcp_bpf_sendmsg()
 tcp_bpf_send_verdict()
  sk_msg_return()
  tcp_bpf_sendmsg_redir()
   unlikely(!psock))
     sk_msg_free()

The mem of msg has been uncharged in tcp_bpf_send_verdict() by
sk_msg_return(), and would be uncharged by sk_msg_free() again. When psock
is null, we can simply returning an error code, this would then trigger
the sk_msg_free_nocharge in the error path of __SK_REDIRECT and would have
the side effect of throwing an error up to user space. This would be a
slight change in behavior from user side but would look the same as an
error if the redirect on the socket threw an error.

This issue can cause the following info:
WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
 <TASK>
 __sk_destruct+0x24/0x1f0
 sk_psock_destroy+0x19b/0x1c0
 process_one_work+0x1b3/0x3c0
 worker_thread+0x30/0x350
 ? process_one_work+0x3c0/0x3c0
 kthread+0xe6/0x110
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30
 </TASK>
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/223f3c51ab163852dd4819d357dcf[PII_REDACTED]4; https://git.kernel.org/stable/c/2486ab434b2c2a14e9237296db00b1e1b7ae3273; https://git.kernel.org/stable/c/94c6ac22abcdede72bfaa0f4c22fb370891f4002
CVE: CVE-2022-49206
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Fix memory leak in error flow for subscribe event routine

In case the second xa_insert() fails, the obj_event is not released.  Fix
the error unwind flow to free that memory to avoid a memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0174a89663a5ef83617da15bf24c0af2f62b6c7f; https://git.kernel.org/stable/c/087f9c3f2309ed183f7e4b85ae57121d8663224d; https://git.kernel.org/stable/c/414b4e[PII_REDACTED]f18d6c4e780787c80dbf8a2c
CVE: CVE-2022-49207
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix memleak in sk_psock_queue_msg

If tcp_bpf_sendmsg is running during a tear down operation we may enqueue
data on the ingress msg queue while tear down is trying to free it.

 sk1 (redirect sk2)                         sk2
 -------------------                      ---------------
tcp_bpf_sendmsg()
 tcp_bpf_send_verdict()
  tcp_bpf_sendmsg_redir()
   bpf_tcp_ingress()
                                          sock_map_close()
                                           lock_sock()
    lock_sock() ... blocking
                                           sk_psock_stop
                                            sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED);
                                           release_sock(sk);
    lock_sock()
    sk_mem_charge()
    get_page()
    sk_psock_queue_msg()
     sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED);
      drop_sk_msg()
    release_sock()

While drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge
and has sg pages need to put. To fix we use sk_msg_free() and then kfee()
msg.

This issue can cause the following info:
WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0
Call Trace:
 <IRQ>
 inet_csk_destroy_sock+0x55/0x110
 tcp_rcv_state_process+0xe5f/0xe90
 ? sk_filter_trim_cap+0x10d/0x230
 ? tcp_v4_do_rcv+0x161/0x250
 tcp_v4_do_rcv+0x161/0x250
 tcp_v4_rcv+0xc3a/0xce0
 ip_protocol_deliver_rcu+0x3d/0x230
 ip_local_deliver_finish+0x54/0x60
 ip_local_deliver+0xfd/0x110
 ? ip_protocol_deliver_rcu+0x230/0x230
 ip_rcv+0xd6/0x100
 ? ip_local_deliver+0x110/0x110
 __netif_receive_skb_one_core+0x85/0xa0
 process_backlog+0xa4/0x160
 __napi_poll+0x29/0x1b0
 net_rx_action+0x287/0x300
 __do_softirq+0xff/0x2fc
 do_softirq+0x79/0x90
 </IRQ>

WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0
Call Trace:
 <TASK>
 __sk_destruct+0x24/0x1f0
 sk_psock_destroy+0x19b/0x1c0
 process_one_work+0x1b3/0x3c0
 ? process_one_work+0x3c0/0x3c0
 worker_thread+0x30/0x350
 ? process_one_work+0x3c0/0x3c0
 kthread+0xe6/0x110
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30
 </TASK>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/03948ed6553960db62f1c33bec29e64d7c191a3f; https://git.kernel.org/stable/c/4dd2e947d3be13a4de3b3028859b9a6497266bcf; https://git.kernel.org/stable/c/938d3480b92fa5e454b7734294f12a7b75126f09
CVE: CVE-2022-49208
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/irdma: Prevent some integer underflows

My static checker complains that:

    drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init()
    warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'?

It appears that "info->dev->hmc_fpm_misc.max_ceqs" comes from the firmware
in irdma_sc_parse_fpm_query_buf() so, yes, there is a chance that it could
be zero.  Even if we trust the firmware, it's easy enough to change the
condition just as a hardenning measure.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191, CWE-191
References: https://git.kernel.org/stable/c/6f6dbb819dfc1a35bcb8b709b5c83a3ea8beff75; https://git.kernel.org/stable/c/7340c3675d7ac946f4019b84cd7c64ed542dfe4c; https://git.kernel.org/stable/c/d52dab6e03550f9c97121b0c11c0a3ed78ee76a4
CVE: CVE-2022-49209
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full

If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.

Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.

This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
 <TASK>
 inet_csk_destroy_sock+0x55/0x110
 __tcp_close+0x279/0x470
 tcp_close+0x1f/0x60
 inet_release+0x3f/0x80
 __sock_release+0x3d/0xb0
 sock_close+0x11/0x20
 __fput+0x92/0x250
 task_work_run+0x6a/0xa0
 do_exit+0x33b/0xb60
 do_group_exit+0x2f/0xa0
 get_signal+0xb6/0x950
 arch_do_signal_or_restart+0xac/0x2a0
 exit_to_user_mode_prepare+0xa9/0x200
 syscall_exit_to_user_mode+0x12/0x30
 do_syscall_64+0x46/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
 </TASK>

WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
 <TASK>
 __sk_destruct+0x24/0x1f0
 sk_psock_destroy+0x19b/0x1c0
 process_one_work+0x1b3/0x3c0
 kthread+0xe6/0x110
 ret_from_fork+0x22/0x30
 </TASK>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/6d03722c34d9603df325f67c6d30dc1b7b3c6067; https://git.kernel.org/stable/c/9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8; https://git.kernel.org/stable/c/bec34a91eba3483e1830c02bdd36f8f968642047
CVE: CVE-2022-49210
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

MIPS: pgalloc: fix memory leak caused by pgd_free()

pgd page is freed by generic implementation pgd_free() since commit
f9cb654cb550 ("asm-generic: pgalloc: provide generic pgd_free()"),
however, there are scenarios that the system uses more than one page as
the pgd table, in such cases the generic implementation pgd_free() won't
be applicable anymore. For example, when PAGE_SIZE_4KB is enabled and
MIPS_VA_BITS_48 is not enabled in a 64bit system, the macro "PGD_ORDER"
will be set as "1", which will cause allocating two pages as the pgd
table. Well, at the same time, the generic implementation pgd_free()
just free one pgd page, which will result in the memory leak.

The memory leak can be easily detected by executing shell command:
"while true; do ls > /dev/null; grep MemFree /proc/meminfo; done"
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/1bf0d78c8cc3cf615a6e7bf33ada70b73592f0a1; https://git.kernel.org/stable/c/2bc5bab9a763d520937e4f3fe8df51c6a1eceb97; https://git.kernel.org/stable/c/5a8501d34b261906e4c76ec9da679f2cb4d309ed
CVE: CVE-2022-49211
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

mips: cdmm: Fix refcount leak in mips_cdmm_phys_base

The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4528668ca331f7ce5999b7746657b46db5b3b785; https://git.kernel.org/stable/c/4680c2ac9aabda82acd23ebbd1f900fb6a889cd3; https://git.kernel.org/stable/c/69155dc2e04777aa94207a73a8b10f12b8428a68
CVE: CVE-2022-49212
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init

The reference counting issue happens in several error handling paths
on a refcounted object "nc->dmac". In these paths, the function simply
returns the error code, forgetting to balance the reference count of
"nc->dmac", increased earlier by dma_request_channel(), which may
cause refcount leaks.

Fix it by decrementing the refcount of specific object in those error
paths.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0856bf27057561f42b37df111603cf5a0d040294; https://git.kernel.org/stable/c/8baea2b96fa90af8d0f937caf4cf2105ee094d93; https://git.kernel.org/stable/c/9843c9c98f26c6ad843260b19bfdaa2598f2ae1e
CVE: CVE-2022-49213
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ath10k: Fix error handling in ath10k_setup_msa_resources

The device_node pointer is returned by of_parse_phandle() with refcount
incremented. We should use of_node_put() on it when done.

This function only calls of_node_put() in the regular path.
And it will cause refcount leak in error path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/315772133a4b960859e4f5efe0e738e347188cdc; https://git.kernel.org/stable/c/32939187f254171a5666badc058bc3787fe454af; https://git.kernel.org/stable/c/4ed37d611ea5d222c3ecb3549e4c2d34b8f3c335
CVE: CVE-2022-49214
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/64s: Don't use DSISR for SLB faults

Since commit 46ddcb3950a2 ("powerpc/mm: Show if a bad page fault on data
is read or write.") we use page_fault_is_write(regs->dsisr) in
__bad_page_fault() to determine if the fault is for a read or write, and
change the message printed accordingly.

But SLB faults, aka Data Segment Interrupts, don't set DSISR (Data
Storage Interrupt Status Register) to a useful value. All ISA versions
from v2.03 through v3.1 specify that the Data Segment Interrupt sets
DSISR "to an undefined value". As far as I can see there's no mention of
SLB faults setting DSISR in any BookIV content either.

This manifests as accesses that should be a read being incorrectly
reported as writes, for example, using the xmon "dump" command:

  0:mon> d 0x5deadbeef0000000
  5deadbeef0000000
  [[PII_REDACTED]54][    C6] BUG: Unable to handle kernel data access on write at 0x5deadbeef0000000
  [[PII_REDACTED]11][    C6] Faulting instruction address: 0xc[PII_REDACTED]0a300
  cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400]
      pc: c[PII_REDACTED]0a300: mread+0x90/0x190

If we disassemble the PC, we see a load instruction:

  0:mon> di c[PII_REDACTED]0a300
  c[PII_REDACTED]0a[PII_REDACTED]0      lbz     r10,0(r9)

We can also see in exceptions-64s.S that the data_access_slb block
doesn't set IDSISR=1, which means it doesn't load DSISR into pt_regs. So
the value we're using to determine if the fault is a read/write is some
stale value in pt_regs from a previous page fault.

Rework the printing logic to separate the SLB fault case out, and only
print read/write in the cases where we can determine it.

The result looks like eg:

  0:mon> d 0x5deadbeef0000000
  5deadbeef0000000
  [  721.779525][    C6] BUG: Unable to handle kernel data access at 0x5deadbeef0000000
  [  721.779697][    C6] Faulting instruction address: 0xc[PII_REDACTED]4cbe0
  cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]

  0:mon> d 0
  [PII_REDACTED]
  [  742.793242][    C6] BUG: Kernel NULL pointer dereference at 0x00000000
  [  742.793316][    C6] Faulting instruction address: 0xc[PII_REDACTED]4cbe0
  cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/093449bb182db885dae816d62874cccab7a4c42a; https://git.kernel.org/stable/c/4a852ff9b7bea9c640540e2c1bc70bd3ba455d61; https://git.kernel.org/stable/c/a3dae36d632b2cf6eb20314273e512a96cb43c9a
CVE: CVE-2022-49216
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/tegra: Fix reference leak in tegra_dsi_ganged_probe

The reference taken by 'of_find_device_by_node()' must be released when
not needed anymore. Add put_device() call to fix this.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0e2f4e434e71dffd1085c3dccd676514bd71d316; https://git.kernel.org/stable/c/1e06710c43a090f14bb67714265a01cd1d7a37c5; https://git.kernel.org/stable/c/221e3638feb8bc42143833c9a704fa89b6c366bb
CVE: CVE-2022-49217
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: pm8001: Fix abort all task initialization

In pm80xx_send_abort_all(), the n_elem field of the ccb used is not
initialized to 0. This missing initialization sometimes lead to the task
completion path seeing the ccb with a non-zero n_elem resulting in the
execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),
causing a crash such as:

[  197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280
[  197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012
[  197.705485] RAX: dffffc[PII_REDACTED] RBX: [PII_REDACTED] RCX: ffffffff83d0bda0
[  197.712687] RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff88810dffc0d0
[  197.719887] RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: ffff8881c790098b
[  197.727089] R10: ffffed1038f20131 R11: [PII_REDACTED] R12: [PII_REDACTED]
[  197.734296] R13: ffff88810dffc0d0 R14: [PII_REDACTED] R15: [PII_REDACTED]
[  197.741493] FS:  [PII_REDACTED](0000) GS:ffff889bbcf80000(0000) knlGS:[PII_REDACTED]
[  197.749659] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[  197.755459] CR2: 00007f16c1b42734 CR3: [PII_REDACTED] CR4:[PII_REDACTED]350ee0
[  197.762656] Call Trace:
[  197.765127]  <IRQ>
[  197.767162]  pm8001_ccb_task_free+0x5f1/0x820 [pm80xx]
[  197.772364]  ? do_raw_spin_unlock+0x54/0x220
[  197.776680]  pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx]
[  197.782406]  process_oq+0xe85/0x7890 [pm80xx]
[  197.786817]  ? lock_acquire+0x194/0x490
[  197.790697]  ? handle_irq_event+0x10e/0x1b0
[  197.794920]  ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx]
[  197.800378]  ? __wake_up_bit+0x100/0x100
[  197.804340]  ? lock_is_held_type+0x98/0x110
[  197.808565]  pm80xx_chip_isr+0x94/0x130 [pm80xx]
[  197.813243]  tasklet_action_common.constprop.0+0x24b/0x2f0
[  197.818785]  __do_softirq+0x1b5/0x82d
[  197.822485]  ? do_raw_spin_unlock+0x54/0x220
[  197.826799]  __irq_exit_rcu+0x17e/0x1e0
[  197.830678]  irq_exit_rcu+0xa/0x20
[  197.834114]  common_interrupt+0x78/0x90
[  197.840051]  </IRQ>
[  197.844236]  <TASK>
[  197.848397]  asm_common_interrupt+0x1e/0x40

Avoid this issue by always initializing the ccb n_elem field to 0 in
pm8001_send_abort_all(), pm8001_send_read_log() and
pm80xx_send_abort_all().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-909
References: https://git.kernel.org/stable/c/16cd02e0951b520bef324adb9a35afcc92501caf; https://git.kernel.org/stable/c/1824a21b2cedc5774a5adfa74f5f7b90472d8677; https://git.kernel.org/stable/c/279f318bd7d6e04e6e0bc7b8cd8e190da8fa37a4
CVE: CVE-2022-49218
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/dp: Fix OOB read when handling Post Cursor2 register

The link_status array was not large enough to read the Adjust Request
Post Cursor2 register, so remove the common helper function to avoid
an OOB read, found with a -Warray-bounds build:

drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor':
drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds]
   59 |         return link_status[r - DP_LANE0_1_STATUS];
      |                ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'
  147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
      |                                          ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Replace the only user of the helper with an open-coded fetch and decode,
similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/a2151490cc6c57b368d7974ffd447a8b36ade639; https://git.kernel.org/stable/c/aeaed9a9fe694f8b1462fb81e2d33298c929180b