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

x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD

Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and
commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a
per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in
order to avoid unnecessary writes to the MSR.

On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which
wipes out any stale state. But the per CPU cached xfd value is not
reset, which brings them out of sync.

As a consequence a subsequent xfd_update_state() might fail to update
the MSR which in turn can result in XRSTOR raising a #NM in kernel
space, which crashes the kernel.

To fix this, introduce xfd_set_state() to write xfd_state together
with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/10e4b5166df9ff7a2d5316138ca668b42d004422; https://git.kernel.org/stable/c/1acbca933313aa866e39996904c9aca4d435c4cd; https://git.kernel.org/stable/c/21c7c00dae55cb0e3810d5f9506b58f68475d41d
CVE: CVE-2024-35802
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-35803
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/efistub: Call mixed mode boot services on the firmware's stack

Normally, the EFI stub calls into the EFI boot services using the stack
that was live when the stub was entered. According to the UEFI spec,
this stack needs to be at least 128k in size - this might seem large but
all asynchronous processing and event handling in EFI runs from the same
stack and so quite a lot of space may be used in practice.

In mixed mode, the situation is a bit different: the bootloader calls
the 32-bit EFI stub entry point, which calls the decompressor's 32-bit
entry point, where the boot stack is set up, using a fixed allocation
of 16k. This stack is still in use when the EFI stub is started in
64-bit mode, and so all calls back into the EFI firmware will be using
the decompressor's limited boot stack.

Due to the placement of the boot stack right after the boot heap, any
stack overruns have gone unnoticed. However, commit

  5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code")

moved the definition of the boot heap into C code, and now the boot
stack is placed right at the base of BSS, where any overruns will
corrupt the end of the .data section.

While it would be possible to work around this by increasing the size of
the boot stack, doing so would affect all x86 systems, and mixed mode
systems are a tiny (and shrinking) fraction of the x86 installed base.

So instead, record the firmware stack pointer value when entering from
the 32-bit firmware, and switch to this stack every time a EFI boot
service call is made.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926; https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc; https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31
CVE: CVE-2024-35804
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Mark target gfn of emulated atomic instruction as dirty

When emulating an atomic access on behalf of the guest, mark the target
gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault.  This
fixes a bug where KVM effectively corrupts guest memory during live
migration by writing to guest memory without informing userspace that the
page is dirty.

Marking the page dirty got unintentionally dropped when KVM's emulated
CMPXCHG was converted to do a user access.  Before that, KVM explicitly
mapped the guest page into kernel memory, and marked the page dirty during
the unmap phase.

Mark the page dirty even if the CMPXCHG fails, as the old data is written
back on failure, i.e. the page is still written.  The value written is
guaranteed to be the same because the operation is atomic, but KVM's ABI
is that all writes are dirty logged regardless of the value written.  And
more importantly, that's what KVM did before the buggy commit.

Huge kudos to the folks on the Cc list (and many others), who did all the
actual work of triaging and debugging.

base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd45c0c71; https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06; https://git.kernel.org/stable/c/910c57dfa4d113aae6571c2a8b9ae8c430975902
CVE: CVE-2024-35805
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

dm snapshot: fix lockup in dm_exception_table_exit

There was reported lockup when we exit a snapshot with many exceptions.
Fix this by adding "cond_resched" to the loop that frees the exceptions.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7; https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1; https://git.kernel.org/stable/c/5f4ad4d0b[PII_REDACTED]313db60b3f84df4aad683
CVE: CVE-2024-35806
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

soc: fsl: qbman: Always disable interrupts when taking cgr_lock

smp_call_function_single disables IRQs when executing the callback. To
prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
This is already done by qman_update_cgr and qman_delete_cgr; fix the
other lockers.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397; https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f; https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3
CVE: CVE-2024-35807
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix corruption during on-line resize

We observed a corruption during on-line resize of a file system that is
larger than 16 TiB with 4k block size. With having more then 2^32 blocks
resize_inode is turned off by default by mke2fs. The issue can be
reproduced on a smaller file system for convenience by explicitly
turning off resize_inode. An on-line resize across an 8 GiB boundary (the
size of a meta block group in this setup) then leads to a corruption:

  dev=/dev/<some_dev> # should be >= 16 GiB
  mkdir -p /corruption
  /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))
  mount -t ext4 $dev /corruption

  dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))
  sha1sum /corruption/test
  # 79d2658b39dcfd77274e435b0934028adafaab11  /corruption/test

  /sbin/resize2fs $dev $((2*2**21))
  # drop page cache to force reload the block from disk
  echo 1 > /proc/sys/vm/drop_caches

  sha1sum /corruption/test
  # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3  /corruption/test

2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per
block group and 2^6 are the number of block groups that make a meta
block group.

The last checksum might be different depending on how the file is laid
out across the physical blocks. The actual corruption occurs at physical
block 63*2^15 = 2064384 which would be the location of the backup of the
meta block group's block descriptor. During the on-line resize the file
system will be converted to meta_bg starting at s_first_meta_bg which is
2 in the example - meaning all block groups after 16 GiB. However, in
ext4_flex_group_add we might add block groups that are not part of the
first meta block group yet. In the reproducer we achieved this by
substracting the size of a whole block group from the point where the
meta block group would start. This must be considered when updating the
backup block group descriptors to follow the non-meta_bg layout. The fix
is to add a test whether the group to add is already part of the meta
block group or not.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/239c669edb2bffa1aa2612519b1d438ab35d6be6; https://git.kernel.org/stable/c/37b6a3ba793bbbae057f5b991970ebcc52cb3db5; https://git.kernel.org/stable/c/722d2c01b8b108f8283d1b7222209d5b2a5aa7bd
CVE: CVE-2024-35808
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

md/dm-raid: don't call md_reap_sync_thread() directly

Currently md_reap_sync_thread() is called from raid_message() directly
without holding 'reconfig_mutex', this is definitely unsafe because
md_reap_sync_thread() can change many fields that is protected by
'reconfig_mutex'.

However, hold 'reconfig_mutex' here is still problematic because this
will cause deadlock, for example, commit 130443d60b1b ("md: refactor
idle/frozen_sync_thread() to fix deadlock").

Fix this problem by using stop_sync_thread() to unregister sync_thread,
like md/raid did.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc; https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669; https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0
CVE: CVE-2024-35809
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI/PM: Drain runtime-idle callbacks before driver removal

A race condition between the .runtime_idle() callback and the .remove()
callback in the rtsx_pcr PCI driver leads to a kernel crash due to an
unhandled page fault [1].

The problem is that rtsx_pci_runtime_idle() is not expected to be running
after pm_runtime_get_sync() has been called, but the latter doesn't really
guarantee that.  It only guarantees that the suspend and resume callbacks
will not be running when it returns.

However, if a .runtime_idle() callback is already running when
pm_runtime_get_sync() is called, the latter will notice that the runtime PM
status of the device is RPM_ACTIVE and it will return right away without
waiting for the former to complete.  In fact, it cannot wait for
.runtime_idle() to complete because it may be called from that callback (it
arguably does not make much sense to do that, but it is not strictly
prohibited).

Thus in general, whoever is providing a .runtime_idle() callback needs
to protect it from running in parallel with whatever code runs after
pm_runtime_get_sync().  [Note that .runtime_idle() will not start after
pm_runtime_get_sync() has returned, but it may continue running then if it
has started earlier.]

One way to address that race condition is to call pm_runtime_barrier()
after pm_runtime_get_sync() (not before it, because a nonzero value of the
runtime PM usage counter is necessary to prevent runtime PM callbacks from
being invoked) to wait for the .runtime_idle() callback to complete should
it be running at that point.  A suitable place for doing that is in
pci_device_remove() which calls pm_runtime_get_sync() before removing the
driver, so it may as well call pm_runtime_barrier() subsequently, which
will prevent the race in question from occurring, not just in the rtsx_pcr
driver, but in any PCI drivers providing .runtime_idle() callbacks.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/47d8aafcfe313511a98f165a54d0adceb34e54b1; https://git.kernel.org/stable/c/6347348c6aba52dda0b33296684cbb627bdc6970; https://git.kernel.org/stable/c/7cc94dd36e48879e76ae7a8daea4ff322b7d9674
CVE: CVE-2024-35810
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: Fix the lifetime of the bo cursor memory

The cleanup can be dispatched while the atomic update is still active,
which means that the memory acquired in the atomic update needs to
not be invalidated by the cleanup. The buffer objects in vmw_plane_state
instead of using the builtin map_and_cache were trying to handle
the lifetime of the mapped memory themselves, leading to crashes.

Use the map_and_cache instead of trying to manage the lifetime of the
buffer objects held by the vmw_plane_state.

Fixes kernel oops'es in IGT's kms_cursor_legacy forked-bo.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/104a5b2772bc7c0715ae7355ccf9d294a472765c; https://git.kernel.org/stable/c/86cb706a40b7e6b2221ee49a298a65ad9b46c02d; https://git.kernel.org/stable/c/9a9e8a7159ca09af9b1a300a6c8e8b6ff7501c76
CVE: CVE-2024-35811
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach

This is the candidate patch of CVE-2023-47233 :
https://nvd.nist.gov/vuln/detail/CVE-2023-47233

In brcm80211 driver,it starts with the following invoking chain
to start init a timeout worker:

->brcmf_usb_probe
  ->brcmf_usb_probe_cb
    ->brcmf_attach
      ->brcmf_bus_started
        ->brcmf_cfg80211_attach
          ->wl_init_priv
            ->brcmf_init_escan
              ->INIT_WORK(&cfg->escan_timeout_work,
		  brcmf_cfg80211_escan_timeout_worker);

If we disconnect the USB by hotplug, it will call
brcmf_usb_disconnect to make cleanup. The invoking chain is :

brcmf_usb_disconnect
  ->brcmf_usb_disconnect_cb
    ->brcmf_detach
      ->brcmf_cfg80211_detach
        ->kfree(cfg);

While the timeout woker may still be running. This will cause
a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.

Fix it by deleting the timer and canceling the worker in
brcmf_cfg80211_detach.

[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb; https://git.kernel.org/stable/c/0b812f706fd7090be[PII_REDACTED]4a0e165b36744; https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78
CVE: CVE-2024-35812
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-35813
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: core: Avoid negative index with array access

Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns
prev_idata = idatas[i - 1], but doesn't check that the iterator i is
greater than zero. Let's fix this by adding a check.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/064db53f9023a2d5877a2d12de6bc27995f6ca56; https://git.kernel.org/stable/c/2b539c88940e22494da80a93ee1c5a28bbad10f6; https://git.kernel.org/stable/c/4466677dcabe2d70de6aa3d4bd4a4fafa94a71f2
CVE: CVE-2024-35814
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

swiotlb: Fix double-allocation of slots due to broken alignment handling

Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"),
which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment
checks"), causes a functional regression with vsock in a virtual machine
using bouncing via a restricted DMA SWIOTLB pool.

When virtio allocates the virtqueues for the vsock device using
dma_alloc_coherent(), the SWIOTLB search can return page-unaligned
allocations if 'area->index' was left unaligned by a previous allocation
from the buffer:

 # Final address in brackets is the SWIOTLB address returned to the caller
 | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800)
 | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800)
 | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)

This ends badly (typically buffer corruption and/or a hang) because
swiotlb_alloc() is expecting a page-aligned allocation and so blindly
returns a pointer to the 'struct page' corresponding to the allocation,
therefore double-allocating the first half (2KiB slot) of the 4KiB page.

Fix the problem by treating the allocation alignment separately to any
additional alignment requirements from the device, using the maximum
of the two as the stride to search the buffer slots and taking care
to ensure a minimum of page-alignment for buffers larger than a page.

This also resolves swiotlb allocation failures occuring due to the
inclusion of ~PAGE_MASK in 'iotlb_align_mask' for large allocations and
resulting in alignment requirements exceeding swiotlb_max_mapping_size().
CVSS Score: 8.8 (HIGH)
CWE: CWE-415, CWE-119, CWE-1055
References: https://git.kernel.org/stable/c/04867a7a33324c9c562ee7949dbcaab7aaad1fb4; https://git.kernel.org/stable/c/3e7acd6e25ba77dde48c3b721c54c89cd6a10534; https://git.kernel.org/stable/c/[PII_REDACTED]71040e12cc40d3d0d178f70c616491
CVE: CVE-2024-35815
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion

The first kiocb_set_cancel_fn() argument may point at a struct kiocb
that is not embedded inside struct aio_kiocb. With the current code,
depending on the compiler, the req->ki_ctx read happens either before
the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such
that it is guaranteed that the IOCB_AIO_RW test happens first.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/10ca82aff58434e122c7c757cf0497c335f993f3; https://git.kernel.org/stable/c/18d5fc3c16cc317bd0e5f5dabe0660df415cadb7; https://git.kernel.org/stable/c/396dbbc18963648e9d1a4edbb55cfe08fa374d50
CVE: CVE-2024-35816
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

firewire: ohci: prevent leak of left-over IRQ on unbind

Commit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ")
also removed the call to free_irq() in pci_remove(), leading to a
leftover irq of devm_request_irq() at pci_disable_msi() in pci_remove()
when unbinding the driver from the device

remove_proc_entry: removing non-empty directory 'irq/136', leaking at
least 'firewire_ohci'
Call Trace:
 ? remove_proc_entry+0x19c/0x1c0
 ? __warn+0x81/0x130
 ? remove_proc_entry+0x19c/0x1c0
 ? report_bug+0x171/0x1a0
 ? console_unlock+0x78/0x120
 ? handle_bug+0x3c/0x80
 ? exc_invalid_op+0x17/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? remove_proc_entry+0x19c/0x1c0
 unregister_irq_proc+0xf4/0x120
 free_desc+0x3d/0xe0
 ? kfree+0x29f/0x2f0
 irq_free_descs+0x47/0x70
 msi_domain_free_locked.part.0+0x19d/0x1d0
 msi_domain_free_irqs_all_locked+0x81/0xc0
 pci_free_msi_irqs+0x12/0x40
 pci_disable_msi+0x4c/0x60
 pci_remove+0x9d/0xc0 [firewire_ohci
     01b483699bebf9cb07a3d69df0aa2bee71db1b26]
 pci_device_remove+0x37/0xa0
 device_release_driver_internal+0x19f/0x200
 unbind_store+0xa1/0xb0

remove irq with devm_free_irq() before pci_disable_msi()
also remove it in fail_msi: of pci_probe() as this would lead to
an identical leak
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/318f6d53dd425c400e35f1a9b7af682c2c6a66d6; https://git.kernel.org/stable/c/43c70cbc2502cf2557105c662eeed6a15d082b88; https://git.kernel.org/stable/c/575801663c7dc38f826212b39e3b91a4a8661c33
CVE: CVE-2024-35817
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag

Otherwise after the GTT bo is released, the GTT and gart space is freed
but amdgpu_ttm_backend_unbind will not clear the gart page table entry
and leave valid mapping entry pointing to the stale system page. Then
if GPU access the gart address mistakely, it will read undefined value
instead page fault, harder to debug and reproduce the real issue.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/589c414138a1bed98e652c905937d8f790804efe; https://git.kernel.org/stable/c/5cdce3dda3b3dacde902f63a8ee72c2b7f91912d; https://git.kernel.org/stable/c/5d5f1a7f3b1039925f79c7894f153c2a905201fb
CVE: CVE-2024-35818
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Define the __io_aw() hook as mmiowb()

Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of
mmiowb()") remove all mmiowb() in drivers, but it says:

"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
spin_unlock(). However, pairing each mmiowb() removal in this patch with
the corresponding call to spin_unlock() is not at all trivial, so there
is a small chance that this change may regress any drivers incorrectly
relying on mmiowb() to order MMIO writes between CPUs using lock-free
synchronisation."

The mmio in radeon_ring_commit() is protected by a mutex rather than a
spinlock, but in the mutex fastpath it behaves similar to spinlock. We
can add mmiowb() calls in the radeon driver but the maintainer says he
doesn't like such a workaround, and radeon is not the only example of
mutex protected mmio.

So we should extend the mmiowb tracking system from spinlock to mutex,
and maybe other locking primitives. This is not easy and error prone, so
we solve it in the architectural code, by simply defining the __io_aw()
hook as mmiowb(). And we no longer need to override queued_spin_unlock()
so use the generic definition.

Without this, we get such an error when run 'glxgears' on weak ordering
architectures such as LoongArch:

radeon 0000:04:00.0: ring 0 stalled for more than 10324msec
radeon 0000:04:00.0: ring 3 stalled for more than 10240msec
radeon 0000:04:00.0: GPU lockup (current fence id 0x[PII_REDACTED]01f412 last fence id 0x[PII_REDACTED]01f414 on ring 3)
radeon 0000:04:00.0: GPU lockup (current fence id 0x[PII_REDACTED]00f940 last fence id 0x[PII_REDACTED]00f941 on ring 0)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0; https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167; https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb
CVE: CVE-2024-35819
Published: 2024-05-17
Description: In the Linux kernel, the following vulnerability has been resolved:

soc: fsl: qbman: Use raw spinlock for cgr_lock

smp_call_function always runs its callback in hard IRQ context, even on
PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock
for cgr_lock to ensure we aren't waiting on a sleeping task.

Although this bug has existed for a while, it was not apparent until
commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")
which invokes smp_call_function_single via qman_update_cgr_safe every
time a link goes up or down.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b3fede[PII_REDACTED]ce837c0d284804aa3bc7a02; https://git.kernel.org/stable/c/32edca2f03a6cc42c650ddc3ad83d086e3f365d1; https://git.kernel.org/stable/c/54d26adf64c04f186098b39dba86b86037084baa
CVE: CVE-2024-35820
Published: 2024-05-17
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.