deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-26820
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed

If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER
handler cannot perform VF register successfully as the register call
is received before netvsc_probe is finished. This is because we
register register_netdevice_notifier() very early( even before
vmbus_driver_register()).
To fix this, we try to register each such matching VF( if it is visible
as a netdevice) at the end of netvsc_probe.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/309ef7de5d840e17607e7d65cbf297c0564433ef; https://git.kernel.org/stable/c/4d29a58d96a78728cb01ee29ed70dc4bd642f135; https://git.kernel.org/stable/c/5b10a88f64c0315cfdef45de0aaaa4eef57de0b7
CVE: CVE-2024-26821
Published: 2024-04-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-26822
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: set correct id, uid and cruid for multiuser automounts

When uid, gid and cruid are not specified, we need to dynamically
set them into the filesystem context used for automounting otherwise
they'll end up reusing the values from the parent mount.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2ceba8ae1bd1f5589548cb722a5c583ca3a2dede; https://git.kernel.org/stable/c/4508ec17357094e2075f334948393ddedbb75157; https://git.kernel.org/stable/c/4a6e4c56721a3e6e2550b72ec56aab306c4607a7
CVE: CVE-2024-26823
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v3-its: Restore quirk probing for ACPI-based systems

While refactoring the way the ITSs are probed, the handling of quirks
applicable to ACPI-based platforms was lost. As a result, systems such as
HIP07 lose their GICv4 functionnality, and some other may even fail to
boot, unless they are configured to boot with DT.

Move the enabling of quirks into its_probe_one(), making it common to all
firmware implementations.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4c60c611441f1f1e5de8e00e98ee5a4970778a00; https://git.kernel.org/stable/c/8b02da04ad978827e5ccd675acf170198f747a7a; https://git.kernel.org/stable/c/91a80fff3eeed928b6fba21271f6a9719b22a5d8
CVE: CVE-2024-26824
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: algif_hash - Remove bogus SGL free on zero-length error path

When a zero-length message is hashed by algif_hash, and an error
is triggered, it tries to free an SG list that was never allocated
in the first place.  Fix this by not freeing the SG list on the
zero-length error path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/24c890dd712f6345e382256cae8c97abb0406b70; https://git.kernel.org/stable/c/775f3c1882a493168e08fdb8cde0865c8f3a8a29; https://git.kernel.org/stable/c/9c82920359b7c1eddaf72069bcfe0ffddf088cd0
CVE: CVE-2024-26825
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

nfc: nci: free rx_data_reassembly skb on NCI device cleanup

rx_data_reassembly skb is stored during NCI data exchange for processing
fragmented packets. It is dropped only when the last fragment is processed
or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
However, the NCI device may be deallocated before that which leads to skb
leak.

As by design the rx_data_reassembly skb is bound to the NCI device and
nothing prevents the device to be freed before the skb is processed in
some way and cleaned, free it on the NCI device cleanup.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-459
References: https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1; https://git.kernel.org/stable/c/2f6d16f0520d[PII_REDACTED]ee2f5c131b547d5f9d; https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23
CVE: CVE-2024-26826
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix data re-injection from stale subflow

When the MPTCP PM detects that a subflow is stale, all the packet
scheduler must re-inject all the mptcp-level unacked data. To avoid
acquiring unneeded locks, it first try to check if any unacked data
is present at all in the RTX queue, but such check is currently
broken, as it uses TCP-specific helper on an MPTCP socket.

Funnily enough fuzzers and static checkers are happy, as the accessed
memory still belongs to the mptcp_sock struct, and even from a
functional perspective the recovery completed successfully, as
the short-cut test always failed.

A recent unrelated TCP change - commit d5fed5addb2b ("tcp: reorganize
tcp_sock fast path variables") - exposed the issue, as the tcp field
reorganization makes the mptcp code always skip the re-inection.

Fix the issue dropping the bogus call: we are on a slow path, the early
optimization proved once again to be evil.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/624902eab7abcb8731b333ec73f206d38d839cd8; https://git.kernel.org/stable/c/6673d9f1c2cd984390550dbdf7d5ae07b20abbf8; https://git.kernel.org/stable/c/6f95120f898b40d13fd441225ef511307853c9c2
CVE: CVE-2024-26827
Published: 2024-04-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-26828
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix underflow in parse_server_interfaces()

In this loop, we step through the buffer and after each item we check
if the size_left is greater than the minimum size we need.  However,
the problem is that "bytes_left" is type ssize_t while sizeof() is type
size_t.  That means that because of type promotion, the comparison is
done as an unsigned and if we have negative bytes left the loop
continues instead of ending.
CVSS Score: 6.7 (MEDIUM)
CWE: CWE-191
References: https://git.kernel.org/stable/c/[PII_REDACTED]b4a219abb70f90b06cdcae97f11512; https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204; https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301
CVE: CVE-2024-26829
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

media: ir_toy: fix a memleak in irtoy_tx

When irtoy_command fails, buf should be freed since it is allocated by
irtoy_tx, or there is a memleak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/207557e393a135c1b6fe1df7cc0741d2c1789fff; https://git.kernel.org/stable/c/7219a692ffc00089015ada33b85b334d1a4b6e8e; https://git.kernel.org/stable/c/b37259448bbc70af1d0e52a9dd5559a9c29c9621
CVE: CVE-2024-26830
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

i40e: Do not allow untrusted VF to remove administratively set MAC

Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.

Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.

Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down

[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
    vf 0     link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
[root@host ~]# ip link set enp2s0f0v0 down
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
    vf 0     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
CVSS Score: 6.3 (MEDIUM)
References: https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893; https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc; https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404
CVE: CVE-2024-26831
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

net/handshake: Fix handshake_req_destroy_test1

Recently, handshake_req_destroy_test1 started failing:

Expected handshake_req_destroy_test == req, but
    handshake_req_destroy_test == [PII_REDACTED]
    req ==[PII_REDACTED]f99b40
not ok 11 req_destroy works

This is because "sock_release(sock)" was replaced with "fput(filp)"
to address a memory leak. Note that sock_release() is synchronous
but fput() usually delays the final close and clean-up.

The delay is not consequential in the other cases that were changed
but handshake_req_destroy_test1 is testing that handshake_req_cancel()
followed by closing the file actually does call the ->hp_destroy
method. Thus the PTR_EQ test at the end has to be sure that the
final close is complete before it checks the pointer.

We cannot use a completion here because if ->hp_destroy is never
called (ie, there is an API bug) then the test will hang.

Reported by: Guenter Roeck <linux@roeck-us.net>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4e1d71cabb19ec2586827adfc60d68689c68c194; https://git.kernel.org/stable/c/7f97805b8df6e33850e225e6bd3ebd9e246920af; https://git.kernel.org/stable/c/d74226e03df1bf19848f18344401f254345af912
CVE: CVE-2024-26832
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: zswap: fix missing folio cleanup in writeback race path

In zswap_writeback_entry(), after we get a folio from
__read_swap_cache_async(), we grab the tree lock again to check that the
swap entry was not invalidated and recycled.  If it was, we delete the
folio we just added to the swap cache and exit.

However, __read_swap_cache_async() returns the folio locked when it is
newly allocated, which is always true for this path, and the folio is
ref'd.  Make sure to unlock and put the folio before returning.

This was discovered by code inspection, probably because this path handles
a race condition that should not happen often, and the bug would not crash
the system, it will only strand the folio indefinitely.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-459
References: https://git.kernel.org/stable/c/14f1992430ef9e647b02aa8ca12c5bcb9a1dffea; https://git.kernel.org/stable/c/6156277d1b26cb3fdb6fcbf0686ab[PII_REDACTED]4; https://git.kernel.org/stable/c/e2891c763aa2cff74dd6b5e978411ccf0cf94abe
CVE: CVE-2024-26833
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix memory leak in dm_sw_fini()

After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:

unreferenced object 0xffff896302b45800 (size 1024):
  comm "(udev-worker)", pid 222, jiffies[PII_REDACTED]
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 6265fd77):
    [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
    [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
    [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu]
    [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
    [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
    [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
    [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90
    [<ffffffff996918a3>] pci_device_probe+0xc3/0x230
    [<ffffffff99805872>] really_probe+0xe2/0x480
    [<ffffffff99805c98>] __driver_probe_device+0x78/0x160
    [<ffffffff99805daf>] driver_probe_device+0x1f/0x90
    [<ffffffff9980601e>] __driver_attach+0xce/0x1c0
    [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
    [<ffffffff99804822>] bus_add_driver+0x112/0x210
    [<ffffffff99807245>] driver_register+0x55/0x100
    [<ffffffff990012d1>] do_one_initcall+0x41/0x300

Fix this by freeing dmub_srv after destroying it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2; https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e; https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b
CVE: CVE-2024-26834
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_flow_offload: release dst in case direct xmit path is used

Direct xmit does not use it since it calls dev_queue_xmit() to send
packets, hence it calls dst_release().

kmemleak reports:

unreferenced object 0xffff88814f440900 (size 184):
  comm "softirq", pid 0, jiffies[PII_REDACTED]
  hex dump (first 32 bytes):
    00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff  .`[.............
    21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00  !.P.............
  backtrace (crc cb2bf5d6):
    [<000000003ee17107>] kmem_cache_alloc+0x286/0x340
    [<[PII_REDACTED]a5de2c>] dst_alloc+0x43/0xb0
    [<00000000f0671159>] rt_dst_alloc+0x2e/0x190
    [<00000000fe5092c9>] __mkroute_output+0x244/0x980
    [<000000005fb96fb0>] ip_route_output_flow+0xc0/0x160
    [<[PII_REDACTED]>] nf_ip_route+0xf/0x30
    [<[PII_REDACTED]da1d8e>] nf_route+0x2d/0x60
    [<00000000d1ecd1cb>] nft_flow_route+0x171/0x6a0 [nft_flow_offload]
    [<00000000d9b2fb60>] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload]
    [<000000009f447dbb>] expr_call_ops_eval+0x53/0x330 [nf_tables]
    [<[PII_REDACTED]2e1be6>] nft_do_chain+0x17c/0x840 [nf_tables]
    [<00000000d0551029>] nft_do_chain_inet+0xa1/0x210 [nf_tables]
    [<[PII_REDACTED]c9d5c6>] nf_hook_slow+0x5b/0x160
    [<[PII_REDACTED]eccab1>] ip_forward+0x8b6/0x9b0
    [<[PII_REDACTED]3a269b>] ip_rcv+0x221/0x230
    [<[PII_REDACTED]2872e5>] __netif_receive_skb_one_core+0xfe/0x110
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/13b57b5cd591d5b22f9bbf047b2922967de411f3; https://git.kernel.org/stable/c/2d17cf10179a7de6d8f0128168b84ad0b4a1863f; https://git.kernel.org/stable/c/8762785f459be1cfe6fcf7285c123aad6a3703f0
CVE: CVE-2024-26835
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: set dormant flag on hook register failure

We need to set the dormant flag again if we fail to register
the hooks.

During memory pressure hook registration can fail and we end up
with a table marked as active but no registered hooks.

On table/base chain deletion, nf_tables will attempt to unregister
the hook again which yields a warn splat from the nftables core.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376; https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af; https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be
CVE: CVE-2024-26836
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86: think-lmi: Fix password opcode ordering for workstations

The Lenovo workstations require the password opcode to be run before
the attribute value is changed (if Admin password is enabled).

Tested on some Thinkpads to confirm they are OK with this order too.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/2bfbe1e0aed00ba51d58573c79452fada3f62ed4; https://git.kernel.org/stable/c/2deb10a99671afda30f834e95e5b992a805bba6a; https://git.kernel.org/stable/c/6f7d0f5fd8e440c[PII_REDACTED]ac4ff9a55eec340
CVE: CVE-2024-26838
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/irdma: Fix KASAN issue with tasklet

KASAN testing revealed the following issue assocated with freeing an IRQ.

[50006.466686] Call Trace:
[50006.466691]  <IRQ>
[50006.489538]  dump_stack+0x5c/0x80
[50006.493475]  print_address_description.constprop.6+0x1a/0x150
[50006.499872]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.505742]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.511644]  kasan_report.cold.11+0x7f/0x118
[50006.516572]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.522473]  irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.528232]  irdma_process_ceq+0xb2/0x400 [irdma]
[50006.533601]  ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma]
[50006.540298]  irdma_ceq_dpc+0x44/0x100 [irdma]
[50006.545306]  tasklet_action_common.isra.14+0x148/0x2c0
[50006.551096]  __do_softirq+0x1d0/0xaf8
[50006.555396]  irq_exit_rcu+0x219/0x260
[50006.559670]  irq_exit+0xa/0x20
[50006.563320]  smp_apic_timer_interrupt+0x1bf/0x690
[50006.568645]  apic_timer_interrupt+0xf/0x20
[50006.573341]  </IRQ>

The issue is that a tasklet could be pending on another core racing
the delete of the irq.

Fix by insuring any scheduled tasklet is killed after deleting the
irq.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc; https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824; https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa
CVE: CVE-2024-26839
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

IB/hfi1: Fix a memleak in init_credit_return

When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
init_credit_return should deallocate dd->cr_base and
dd->cr_base[i] that allocated before. Or those resources
would be never freed and a memleak is triggered.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3; https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7; https://git.kernel.org/stable/c/52de5805c[PII_REDACTED]2af89ed7e083d656ae25
CVE: CVE-2024-26840
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

cachefiles: fix memory leak in cachefiles_add_cache()

The following memory leak was reported after unbinding /dev/cachefiles:

==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
  comm "cachefilesd2", pid 680, jiffies[PII_REDACTED]
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc ea38a44b):
    [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
    [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
    [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
    [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
    [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
    [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
    [<ffffffff8ebc5069>] ksys_write+0x69/0xf0
    [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
    [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
==================================================================

Put the reference count of cache_cred in cachefiles_daemon_unbind() to
fix the problem. And also put cache_cred in cachefiles_add_cache() error
branch to avoid memory leaks.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285; https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3; https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8
CVE: CVE-2024-26842
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Fix shift issue in ufshcd_clear_cmd()

When task_tag >= 32 (in MCQ mode) and sizeof(unsigned int) == 4, 1U <<
task_tag will out of bounds for a u32 mask. Fix this up to prevent
SHIFT_ISSUE (bitwise shifts that are out of bounds for their data type).

[name:debug_monitors&]Unexpected kernel BRK exception at EL1
[name:traps&]Internal error: BRK handler: 00000000f2005514 [#1] PREEMPT SMP
[name:mediatek_cpufreq_hw&]cpufreq stop DVFS log done
[name:mrdump&]Kernel Offset: 0x1ba5800000 from 0xffffffc008000000
[name:mrdump&]PHYS_OFFSET: 0x80000000
[name:mrdump&]pstate: 22400005 (nzCv daif +PAN -UAO)
[name:mrdump&]pc : [0xffffffdbaf52bb2c] ufshcd_clear_cmd+0x280/0x288
[name:mrdump&]lr : [0xffffffdbaf52a774] ufshcd_wait_for_dev_cmd+0x3e4/0x82c
[name:mrdump&]sp : ffffffc0081471b0
<snip>
Workqueue: ufs_eh_wq_0 ufshcd_err_handler
Call trace:
 dump_backtrace+0xf8/0x144
 show_stack+0x18/0x24
 dump_stack_lvl+0x78/0x9c
 dump_stack+0x18/0x44
 mrdump_common_die+0x254/0x480 [mrdump]
 ipanic_die+0x20/0x30 [mrdump]
 notify_die+0x15c/0x204
 die+0x10c/0x5f8
 arm64_notify_die+0x74/0x13c
 do_debug_exception+0x164/0x26c
 el1_dbg+0x64/0x80
 el1h_64_sync_handler+0x3c/0x90
 el1h_64_sync+0x68/0x6c
 ufshcd_clear_cmd+0x280/0x288
 ufshcd_wait_for_dev_cmd+0x3e4/0x82c
 ufshcd_exec_dev_cmd+0x5bc/0x9ac
 ufshcd_verify_dev_init+0x84/0x1c8
 ufshcd_probe_hba+0x724/0x1ce0
 ufshcd_host_reset_and_restore+0x260/0x574
 ufshcd_reset_and_restore+0x138/0xbd0
 ufshcd_err_handler+0x1218/0x2f28
 process_one_work+0x5fc/0x1140
 worker_thread+0x7d8/0xe20
 kthread+0x25c/0x468
 ret_from_fork+0x10/0x20
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/7ac9e18f5d66087cd22751c5c5bf0090eb0038fe; https://git.kernel.org/stable/c/a992425d18e5f7c[PII_REDACTED]3c6c69426f2a8fb; https://git.kernel.org/stable/c/b513d30d59bb383a6a5d6b533afcab2cee99a8f8
CVE: CVE-2024-26843
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

efi: runtime: Fix potential overflow of soft-reserved region size

md_size will have been narrowed if we have >= 4GB worth of pages in a
soft-reserved region.
CVSS Score: 6.0 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/156cb12ffdcf33883304f0db645e1eadae712fe0; https://git.kernel.org/stable/c/4aa36b62c3eaa869860bf78b1146e9f2b5f782a9; https://git.kernel.org/stable/c/4fff3d735baea104017f2e3c245e27cdc79f2426
CVE: CVE-2024-26844
Published: 2024-04-17
Description: In the Linux kernel, the following vulnerability has been resolved:

block: Fix WARNING in _copy_from_iter

Syzkaller reports a warning in _copy_from_iter because an
iov_iter is supposedly used in the wrong direction. The reason
is that syzcaller managed to generate a request with
a transfer direction of SG_DXFER_TO_FROM_DEV. This instructs
the kernel to copy user buffers into the kernel, read into
the copied buffers and then copy the data back to user space.

Thus the iovec is used in both directions.

Detect this situation in the block layer and construct a new
iterator with the correct direction for the copy-in.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0f1bae071de[PII_REDACTED]472921829a54b2e5956; https://git.kernel.org/stable/c/13f3956eb5681a4045a8dfdef48df5dc4d9f58a6; https://git.kernel.org/stable/c/8fc80874103a5c20aebdc2401361aa01c817f75b