deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-48718
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: mxsfb: Fix NULL pointer dereference

mxsfb should not ever dereference the NULL pointer which
drm_atomic_get_new_bridge_state is allowed to return.
Assume a fixed format instead.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/622c9a3a7868e1eeca39c55305ca3ebec4742b64; https://git.kernel.org/stable/c/6f9267e01cca749137349d8ffb0d0ebbadf567f4; https://git.kernel.org/stable/c/86a337bb803040e4401b87c974a7fb92efe3d0e1
CVE: CVE-2022-48720
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

net: macsec: Fix offload support for NETDEV_UNREGISTER event

Current macsec netdev notify handler handles NETDEV_UNREGISTER event by
releasing relevant SW resources only, this causes resources leak in case
of macsec HW offload, as the underlay driver was not notified to clean
it's macsec offload resources.

Fix by calling the underlay driver to clean it's relevant resources
by moving offload handling from macsec_dellink() to macsec_common_dellink()
when handling NETDEV_UNREGISTER event.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2e7f5b6ee1a7a2c628253a95b0a95b582901ef1b; https://git.kernel.org/stable/c/8299be160aad8548071d080518712dec0df92bd5; https://git.kernel.org/stable/c/9cef24c8b76c1f6effe499d2f131807c90f7ce9a
CVE: CVE-2022-48721
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

net/smc: Forward wakeup to smc socket waitqueue after fallback

When we replace TCP with SMC and a fallback occurs, there may be
some socket waitqueue entries remaining in smc socket->wq, such
as eppoll_entries inserted by userspace applications.

After the fallback, data flows over TCP/IP and only clcsocket->wq
will be woken up. Applications can't be notified by the entries
which were inserted in smc socket->wq before fallback. So we need
a mechanism to wake up smc socket->wq at the same time if some
entries remaining in it.

The current workaround is to transfer the entries from smc socket->wq
to clcsock->wq during the fallback. But this may cause a crash
like this:

 general protection fault, probably for non-canonical address 0xdead[PII_REDACTED]00: 0000 [#1] PREEMPT SMP PTI
 CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E     5.16.0+ #107
 RIP: 0010:__wake_up_common+0x65/0x170
 Call Trace:
  <IRQ>
  __wake_up_common_lock+0x7a/0xc0
  sock_def_readable+0x3c/0x70
  tcp_data_queue+0x4a7/0xc40
  tcp_rcv_established+0x32f/0x660
  ? sk_filter_trim_cap+0xcb/0x2e0
  tcp_v4_do_rcv+0x10b/0x260
  tcp_v4_rcv+0xd2a/0xde0
  ip_protocol_deliver_rcu+0x3b/0x1d0
  ip_local_deliver_finish+0x54/0x60
  ip_local_deliver+0x6a/0x110
  ? tcp_v4_early_demux+0xa2/0x140
  ? tcp_v4_early_demux+0x10d/0x140
  ip_sublist_rcv_finish+0x49/0x60
  ip_sublist_rcv+0x19d/0x230
  ip_list_rcv+0x13e/0x170
  __netif_receive_skb_list_core+0x1c2/0x240
  netif_receive_skb_list_internal+0x1e6/0x320
  napi_complete_done+0x11d/0x190
  mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]
  __napi_poll+0x3c/0x1b0
  net_rx_action+0x27c/0x300
  __do_softirq+0x114/0x2d2
  irq_exit_rcu+0xb4/0xe0
  common_interrupt+0xba/0xe0
  </IRQ>
  <TASK>

The crash is caused by privately transferring waitqueue entries from
smc socket->wq to clcsock->wq. The owners of these entries, such as
epoll, have no idea that the entries have been transferred to a
different socket wait queue and still use original waitqueue spinlock
(smc socket->wq.wait.lock) to make the entries operation exclusive,
but it doesn't work. The operations to the entries, such as removing
from the waitqueue (now is clcsock->wq after fallback), may cause a
crash when clcsock waitqueue is being iterated over at the moment.

This patch tries to fix this by no longer transferring wait queue
entries privately, but introducing own implementations of clcsock's
callback functions in fallback situation. The callback functions will
forward the wakeup to smc socket->wq if clcsock->wq is actually woken
up and smc socket->wq has remaining entries.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0ef6049f664941bc0f75828b3a[PII_REDACTED]8b27; https://git.kernel.org/stable/c/341adeec9adad0874f29a0a1af[PII_REDACTED]2a39; https://git.kernel.org/stable/c/504078fbe9dd570d685361b57784a6050bc40aaa
CVE: CVE-2022-48722
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ieee802154: ca8210: Stop leaking skb's

Upon error the ieee802154_xmit_complete() helper is not called. Only
ieee802154_wake_queue() is called manually. We then leak the skb
structure.

Free the skb structure upon error before returning.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/21feb6df[PII_REDACTED]242c427fe0958276af81cc; https://git.kernel.org/stable/c/621b24b09eb61c63f262da0c9c5f0e93348897e5; https://git.kernel.org/stable/c/6f38d3a6ec11c2733b1c641a46a2a2ecec57be08
CVE: CVE-2022-48723
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: uniphier: fix reference count leak in uniphier_spi_probe()

The issue happens in several error paths in uniphier_spi_probe().
When either dma_get_slave_caps() or devm_spi_register_master() returns
an error code, the function forgets to decrease the refcount of both
`dma_rx` and `dma_tx` objects, which may lead to refcount leaks.

Fix it by decrementing the reference count of specific objects in
those error paths.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/37c2c83ca4f1ef4b6908181ac98e18360af89b42; https://git.kernel.org/stable/c/447c3d4046d7b54052d07d8b27e15e6edea5662c; https://git.kernel.org/stable/c/dd00b4f8f768d81c3788a8ac88fdb3d745e55ea3
CVE: CVE-2024-28147
Published: 2024-06-20
Description: An authenticated user can upload arbitrary files in the upload 
function for collection preview images. An attacker may upload an HTML 
file that includes malicious JavaScript code which will be executed if a
 user visits the direct URL of the collection preview image (Stored 
Cross Site Scripting). It is also possible to upload SVG files that 
include nested XML entities. Those are parsed when a user visits the 
direct URL of the collection preview image, which may be utilized for a 
Denial of Service attack.

This issue affects edu-sharing: <8.0.8-RC2, <8.1.4-RC0, <9.0.0-RC19.
CVSS Score: 7.4 (HIGH)
CWE: CWE-434
References: http://seclists.org/fulldisclosure/2024/Jun/11; https://r.sec-consult.com/metaventis; http://seclists.org/fulldisclosure/2024/Jun/11
CVE: CVE-2024-5036
Published: 2024-06-20
Description: The Sina Extension for Elementor (Slider, Gallery, Form, Modal, Data Table, Tab, Particle, Free Elementor Widgets & Elementor Templates) plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘url’ parameter in all versions up to, and including, 3.5.4 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVSS Score: 6.4 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://plugins.trac.wordpress.org/browser/sina-extension-for-elementor/trunk/widgets/basic/sina-counter.php#L687; https://plugins.trac.wordpress.org/changeset/3104601/; https://www.wordfence.com/threat-intel/vulnerabilities/id/64f11bc9-88b5-43d5-bc76-129dc5909210?source=cve
CVE: CVE-2024-5886
Published: 2024-06-20
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-6181
Published: 2024-06-20
Description: A vulnerability was found in LabVantage LIMS 2017. It has been declared as problematic. This vulnerability affects unknown code of the file /labvantage/rc?command=file&file=WEB-CORE/elements/files/filesembedded.jsp&size=32. The manipulation of the argument height/width leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-269152. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score: 3.5 (LOW)
CWE: CWE-79
References: https://gentle-khaan-c53.notion.site/Reflected-XSS-in-Labvantage-LIMS-9531d77dce984d4da2ddcab863962e9c?pvs=4; https://vuldb.com/?ctiid.269152; https://vuldb.com/?id.269152
CVE: CVE-2024-6182
Published: 2024-06-20
Description: A vulnerability was found in LabVantage LIMS 2017. It has been rated as problematic. This issue affects some unknown processing of the file /labvantage/rc?command=page&page=LV_ViewSampleSpec&oosonly=Y&_sdialog=Y. The manipulation of the argument sdcid/keyid1 leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-269153 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score: 3.5 (LOW)
CWE: CWE-79
References: https://gentle-khaan-c53.notion.site/Reflected-XSS-in-Labvantage-LIMS-95e338b6f9ea45db9a6c635c3c1ff3b8; https://vuldb.com/?ctiid.269153; https://vuldb.com/?id.269153
CVE: CVE-2021-4439
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

isdn: cpai: check ctr->cnr to avoid array index out of bound

The cmtp_add_connection() would add a cmtp session to a controller
and run a kernel thread to process cmtp.

	__module_get(THIS_MODULE);
	session->task = kthread_run(cmtp_session, session, "kcmtpd_ctr_%d",
								session->num);

During this process, the kernel thread would call detach_capi_ctr()
to detach a register controller. if the controller
was not attached yet, detach_capi_ctr() would
trigger an array-index-out-bounds bug.

[   46.866069][ T6479] UBSAN: array-index-out-of-bounds in
drivers/isdn/capi/kcapi.c:483:21
[   46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]'
[   46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted
5.15.0-rc2+ #8
[   46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX,
1996), BIOS 1.14.0-2 04/01/2014
[   46.870107][ T6479] Call Trace:
[   46.870473][ T6479]  dump_stack_lvl+0x57/0x7d
[   46.870974][ T6479]  ubsan_epilogue+0x5/0x40
[   46.871458][ T6479]  __ubsan_handle_out_of_bounds.cold+0x43/0x48
[   46.872135][ T6479]  detach_capi_ctr+0x64/0xc0
[   46.872639][ T6479]  cmtp_session+0x5c8/0x5d0
[   46.873131][ T6479]  ? __init_waitqueue_head+0x60/0x60
[   46.873712][ T6479]  ? cmtp_add_msgpart+0x120/0x120
[   46.874256][ T6479]  kthread+0x147/0x170
[   46.874709][ T6479]  ? set_kthread_struct+0x40/0x40
[   46.875248][ T6479]  ret_from_fork+0x1f/0x30
[   46.875773][ T6479]
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/1f3e2e97c003f80c4b087092b225c8787ff91e4d; https://git.kernel.org/stable/c/24219a977bfe3d658687e45615c70998acdbac5a; https://git.kernel.org/stable/c/285e9210b1fab96a11c0be3ed5cea9dd48b6ac54
CVE: CVE-2022-48724
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping()

After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node
unconditionally allocated"). For tear down scenario, fn is only freed
after fail to allocate ir_domain, though it also should be freed in case
dmar_enable_qi returns error.

Besides free fn, irq_domain and ir_msi_domain need to be removed as well
if intel_setup_irq_remapping fails to enable queued invalidation.

Improve the rewinding path by add out_free_ir_domain and out_free_fwnode
lables per Baolu's suggestion.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/336d096b62bdc673e852b6b80d5072d7888ce85d; https://git.kernel.org/stable/c/5c43d46daa0d2928234dd2792ebebc35d29ee2d1; https://git.kernel.org/stable/c/99e675d473eb8cf2deac1376a0f840222fc1adcf
CVE: CVE-2022-48725
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/siw: Fix refcounting leak in siw_create_qp()

The atomic_inc() needs to be paired with an atomic_dec() on the error
path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2989ba9532babac66e79997ccff73c015b69700c; https://git.kernel.org/stable/c/a75badebfdc0b3823054bedf112edb54d6357c75; https://git.kernel.org/stable/c/fa3b844a50845c817660146c27c0fc29b08d3116
CVE: CVE-2022-48726
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/ucma: Protect mc during concurrent multicast leaves

Partially revert the commit mentioned in the Fixes line to make sure that
allocation and erasing multicast struct are locked.

  BUG: KASAN: use-after-free in ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline]
  BUG: KASAN: use-after-free in ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579
  Read of size 8 at addr ffff88801bb74b00 by task syz-executor.1/25529
  CPU: 0 PID: 25529 Comm: syz-executor.1 Not tainted 5.16.0-rc7-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  Call Trace:
   __dump_stack lib/dump_stack.c:88 [inline]
   dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
   print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247
   __kasan_report mm/kasan/report.c:433 [inline]
   kasan_report.cold+0x83/0xdf mm/kasan/report.c:450
   ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [inline]
   ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c:579
   ucma_destroy_id+0x1e6/0x280 drivers/infiniband/core/ucma.c:614
   ucma_write+0x25c/0x350 drivers/infiniband/core/ucma.c:1732
   vfs_write+0x28e/0xae0 fs/read_write.c:588
   ksys_write+0x1ee/0x250 fs/read_write.c:643
   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
   do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Currently the xarray search can touch a concurrently freeing mc as the
xa_for_each() is not surrounded by any lock. Rather than hold the lock for
a full scan hold it only for the effected items, which is usually an empty
list.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2923948ffe0835f7114e948b35bcc42bc9b3baa1; https://git.kernel.org/stable/c/36e8169ec973359f671f9ec[PII_REDACTED]cae972e; https://git.kernel.org/stable/c/75c610212b9f1756b9384911d3a2c347eee8031c
CVE: CVE-2022-48727
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Avoid consuming a stale esr value when SError occur

When any exception other than an IRQ occurs, the CPU updates the ESR_EL2
register with the exception syndrome. An SError may also become pending,
and will be synchronised by KVM. KVM notes the exception type, and whether
an SError was synchronised in exit_code.

When an exception other than an IRQ occurs, fixup_guest_exit() updates
vcpu->arch.fault.esr_el2 from the hardware register. When an SError was
synchronised, the vcpu esr value is used to determine if the exception
was due to an HVC. If so, ELR_EL2 is moved back one instruction. This
is so that KVM can process the SError first, and re-execute the HVC if
the guest survives the SError.

But if an IRQ synchronises an SError, the vcpu's esr value is stale.
If the previous non-IRQ exception was an HVC, KVM will corrupt ELR_EL2,
causing an unrelated guest instruction to be executed twice.

Check ARM_EXCEPTION_CODE() before messing with ELR_EL2, IRQs don't
update this register so don't need to check.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1c71dbc8a179d99dd9bb7e7fc1888db613cf85de; https://git.kernel.org/stable/c/57e2986c3b25092691a6e3d6ee9168caf8978932; https://git.kernel.org/stable/c/e1e[PII_REDACTED]00f1873f60b954da5f02cc2dba3
CVE: CVE-2022-48728
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

IB/hfi1: Fix AIP early init panic

An early failure in hfi1_ipoib_setup_rn() can lead to the following panic:

  BUG: unable to handle kernel NULL pointer dereference at[PII_REDACTED]0001b0
  PGD 0 P4D 0
  Oops: 0002 [#1] SMP NOPTI
  Workqueue: events work_for_cpu_fn
  RIP: 0010:try_to_grab_pending+0x2b/0x140
  Code: 1f 44 00 00 41 55 41 54 55 48 89 d5 53 48 89 fb 9c 58 0f 1f 44 00 00 48 89 c2 fa 66 0f 1f 44 00 00 48 89 55 00 40 84 f6 75 77 <f0> 48 0f ba 2b 00 72 09 31 c0 5b 5d 41 5c 41 5d c3 48 89 df e8 6c
  RSP: 0018:ffffb6b3cf7cfa48 EFLAGS: 00010046
  RAX: [PII_REDACTED] RBX:[PII_REDACTED]0001b0 RCX: [PII_REDACTED]
  RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI:[PII_REDACTED]0001b0
  RBP: ffffb6b3cf7cfa70 R08:[PII_REDACTED]000f09 R09: [PII_REDACTED]
  R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
  R13: ffffb6b3cf7cfa90 R14: ffffffff9b2fbfc0 R15: ffff8a4fdf244690
  FS:  [PII_REDACTED](0000) GS:ffff8a527f400000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2:[PII_REDACTED]0001b0 CR3: 00000017e2410003 CR4:[PII_REDACTED]7706f0
  DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
  DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
  PKRU: 55555554
  Call Trace:
   __cancel_work_timer+0x42/0x190
   ? dev_printk_emit+0x4e/0x70
   iowait_cancel_work+0x15/0x30 [hfi1]
   hfi1_ipoib_txreq_deinit+0x5a/0x220 [hfi1]
   ? dev_err+0x6c/0x90
   hfi1_ipoib_netdev_dtor+0x15/0x30 [hfi1]
   hfi1_ipoib_setup_rn+0x10e/0x150 [hfi1]
   rdma_init_netdev+0x5a/0x80 [ib_core]
   ? hfi1_ipoib_free_rdma_netdev+0x20/0x20 [hfi1]
   ipoib_intf_init+0x6c/0x350 [ib_ipoib]
   ipoib_intf_alloc+0x5c/0xc0 [ib_ipoib]
   ipoib_add_one+0xbe/0x300 [ib_ipoib]
   add_client_context+0x12c/0x1a0 [ib_core]
   enable_device_and_get+0xdc/0x1d0 [ib_core]
   ib_register_device+0x572/0x6b0 [ib_core]
   rvt_register_device+0x11b/0x220 [rdmavt]
   hfi1_register_ib_device+0x6b4/0x770 [hfi1]
   do_init_one.isra.20+0x3e3/0x680 [hfi1]
   local_pci_probe+0x41/0x90
   work_for_cpu_fn+0x16/0x20
   process_one_work+0x1a7/0x360
   ? create_worker+0x1a0/0x1a0
   worker_thread+0x1cf/0x390
   ? create_worker+0x1a0/0x1a0
   kthread+0x116/0x130
   ? kthread_flush_work_fn+0x10/0x10
   ret_from_fork+0x1f/0x40

The panic happens in hfi1_ipoib_txreq_deinit() because there is a NULL
deref when hfi1_ipoib_netdev_dtor() is called in this error case.

hfi1_ipoib_txreq_init() and hfi1_ipoib_rxq_init() are self unwinding so
fix by adjusting the error paths accordingly.

Other changes:
- hfi1_ipoib_free_rdma_netdev() is deleted including the free_netdev()
  since the netdev core code deletes calls free_netdev()
- The switch to the accelerated entrances is moved to the success path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1899c3cad265c4583658aed5293d02e8af84276b; https://git.kernel.org/stable/c/4a9bd1e6780fc59f81466ec3489d5ad535a37190; https://git.kernel.org/stable/c/5f8f55b92edd621f056bdf09e572092849fabd83
CVE: CVE-2022-48729
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

IB/hfi1: Fix panic with larger ipoib send_queue_size

When the ipoib send_queue_size is increased from the default the following
panic happens:

  RIP: 0010:hfi1_ipoib_drain_tx_ring+0x45/0xf0 [hfi1]
  Code: 31 e4 eb 0f 8b 85 c8 02 00 00 41 83 c4 01 44 39 e0 76 60 8b 8d cc 02 00 00 44 89 e3 be 01 00 00 00 d3 e3 48 03 9d c0 02 00 00 <c7> 83 18 01 00 00 00 00 00 00 48 8b bb 30 01 00 00 e8 25 af a7 e0
  RSP: 0018:ffffc9000798f4a0 EFLAGS: 00010286
  RAX: [PII_REDACTED] RBX: ffffc9000aa0f000 RCX:[PII_REDACTED]00000f
  RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
  RBP: ffff88810ff08000 R08: ffff88889476d900 R09: [PII_REDACTED]
  R10: [PII_REDACTED] R11: ffffc90006590ff8 R12: [PII_REDACTED]
  R13: ffffc9000798fba8 R14: [PII_REDACTED] R15: [PII_REDACTED]
  FS:  00007fd0f79cc3c0(0000) GS:ffff88885fb00000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: ffffc9000aa0f118 CR3:[PII_REDACTED]c84001 CR4:[PII_REDACTED]1706e0
  Call Trace:
   <TASK>
   hfi1_ipoib_napi_tx_disable+0x45/0x60 [hfi1]
   hfi1_ipoib_dev_stop+0x18/0x80 [hfi1]
   ipoib_ib_dev_stop+0x1d/0x40 [ib_ipoib]
   ipoib_stop+0x48/0xc0 [ib_ipoib]
   __dev_close_many+0x9e/0x110
   __dev_change_flags+0xd9/0x210
   dev_change_flags+0x21/0x60
   do_setlink+0x31c/0x10f0
   ? __nla_validate_parse+0x12d/0x1a0
   ? __nla_parse+0x21/0x30
   ? inet6_validate_link_af+0x5e/0xf0
   ? cpumask_next+0x1f/0x20
   ? __snmp6_fill_stats64.isra.53+0xbb/0x140
   ? __nla_validate_parse+0x47/0x1a0
   __rtnl_newlink+0x530/0x910
   ? pskb_expand_head+0x73/0x300
   ? __kmalloc_node_track_caller+0x109/0x280
   ? __nla_put+0xc/0x20
   ? cpumask_next_and+0x20/0x30
   ? update_sd_lb_stats.constprop.144+0xd3/0x820
   ? _raw_spin_unlock_irqrestore+0x25/0x37
   ? __wake_up_common_lock+0x87/0xc0
   ? kmem_cache_alloc_trace+0x3d/0x3d0
   rtnl_newlink+0x43/0x60

The issue happens when the shift that should have been a function of the
txq item size mistakenly used the ring size.

Fix by using the item size.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1530d84fba1e459ba55f46aa42649b88773210e7; https://git.kernel.org/stable/c/8c83d39cc730378bbac64d67a551897b203a606e; https://git.kernel.org/stable/c/1530d84fba1e459ba55f46aa42649b88773210e7
CVE: CVE-2022-48730
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

dma-buf: heaps: Fix potential spectre v1 gadget

It appears like nr could be a Spectre v1 gadget as it's supplied by a
user and used as an array index. Prevent the contents
of kernel memory from being leaked to userspace via speculative
execution by using array_index_nospec.

 [sumits: added fixes and cc: stable tags]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-203
References: https://git.kernel.org/stable/c/24f8e12d965b24f8aea762589e0e9fe2025c005e; https://git.kernel.org/stable/c/5d40f1bdad3dd1a177f21a90ad4353c1ed40ba3a; https://git.kernel.org/stable/c/92c4cfaee[PII_REDACTED]c5b6f2e8e613f9d84d47d
CVE: CVE-2022-48731
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/kmemleak: avoid scanning potential huge holes

When using devm_request_free_mem_region() and devm_memremap_pages() to
add ZONE_DEVICE memory, if requested free mem region's end pfn were
huge(e.g., 0x400000000), the node_end_pfn() will be also huge (see
move_pfn_range_to_zone()).  Thus it creates a huge hole between
node_start_pfn() and node_end_pfn().

We found on some AMD APUs, amdkfd requested such a free mem region and
created a huge hole.  In such a case, following code snippet was just
doing busy test_bit() looping on the huge hole.

  for (pfn = start_pfn; pfn < end_pfn; pfn++) {
	struct page *page = pfn_to_online_page(pfn);
		if (!page)
			continue;
	...
  }

So we got a soft lockup:

  watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221]
  CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1
  RIP: 0010:pfn_to_online_page+0x5/0xd0
  Call Trace:
    ? kmemleak_scan+0x16a/0x440
    kmemleak_write+0x306/0x3a0
    ? common_file_perm+0x72/0x170
    full_proxy_write+0x5c/0x90
    vfs_write+0xb9/0x260
    ksys_write+0x67/0xe0
    __x64_sys_write+0x1a/0x20
    do_syscall_64+0x3b/0xc0
    entry_SYSCALL_64_after_hwframe+0x44/0xae

I did some tests with the patch.

(1) amdgpu module unloaded

before the patch:

  real    0m0.976s
  user    0m0.000s
  sys     0m0.968s

after the patch:

  real    0m0.981s
  user    0m0.000s
  sys     0m0.973s

(2) amdgpu module loaded

before the patch:

  real    0m35.365s
  user    0m0.000s
  sys     0m35.354s

after the patch:

  real    0m1.049s
  user    0m0.000s
  sys     0m1.042s
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134; https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e; https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db