Wind River Support Network

HomeCVE Database

The Common Vulnerabilities and Exposures (CVE) project, maintained by the MITRE Corporation, is a list of all standardized names for vulnerabilities and security exposures.

Reset
Showing
of 228014 entries
IDDescriptionPriorityModified date
CVE-2024-35809 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. -- May 17, 2024
CVE-2024-35808 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. -- May 17, 2024
CVE-2024-35807 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. -- May 17, 2024
CVE-2024-35806 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. -- May 17, 2024
CVE-2024-35805 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. -- May 17, 2024
CVE-2024-35804 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 -- May 17, 2024
CVE-2024-35803 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. -- May 17, 2024
CVE-2024-35802 Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. -- May 17, 2024
CVE-2024-35801 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. -- May 17, 2024
CVE-2024-35800 In the Linux kernel, the following vulnerability has been resolved: efi: fix panic in kdump kernel Check if get_next_variable() is actually valid pointer before calling it. In kdump kernel this method is set to NULL that causes panic during the kexec-ed kernel boot. Tested with QEMU and OVMF firmware. -- May 17, 2024
CVE-2024-35799 In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Prevent crash when disable stream [Why] Disabling stream encoder invokes a function that no longer exists. [How] Check if the function declaration is NULL in disable stream encoder. -- May 17, 2024
CVE-2024-35798 In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race in read_extent_buffer_pages() There are reports from tree-checker that detects corrupted nodes, without any obvious pattern so possibly an overwrite in memory. After some debugging it turns out there\'s a race when reading an extent buffer the uptodate status can be missed. To prevent concurrent reads for the same extent buffer, read_extent_buffer_pages() performs these checks: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) goto done; At this point, it seems safe to start the actual read operation. Once that completes, end_bbio_meta_read() does /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normally, this is enough to ensure only one read happens, and all other callers wait for it to finish before returning. Unfortunately, there is a racey interleaving: Thread A | Thread B | Thread C ---------+----------+--------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) When this happens, thread B kicks of an unnecessary read. Worse, thread C will see UPTODATE set and return immediately, while the read from thread B is still in progress. This race could result in tree-checker errors like this as the extent buffer is concurrently modified: BTRFS critical (device dm-0): corrupted node, root=256 block=8550954455682405139 owner mismatch, have 11858205567642294356 expect [256, 18446744073709551360] Fix it by testing UPTODATE again after setting the READING bit, and if it\'s been set, skip the unnecessary read. [ minor update of changelog ] -- May 17, 2024
CVE-2024-35797 In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix two shmem bugs When cachestat on shmem races with swapping and invalidation, there are two possible bugs: 1) A swapin error can have resulted in a poisoned swap entry in the shmem inode\'s xarray. Calling get_shadow_from_swap_cache() on it will result in an out-of-bounds access to swapper_spaces[]. Validate the entry with non_swap_entry() before going further. 2) When we find a valid swap entry in the shmem\'s inode, the shadow entry in the swapcache might not exist yet: swap IO is still in progress and we\'re before __remove_mapping; swapin, invalidation, or swapoff have removed the shadow from swapcache after we saw the shmem swap entry. This will send a NULL to workingset_test_recent(). The latter purely operates on pointer bits, so it won\'t crash - node 0, memcg ID 0, eviction timestamp 0, etc. are all valid inputs - but it\'s a bogus test. In theory that could result in a false recently evicted count. Such a false positive wouldn\'t be the end of the world. But for code clarity and (future) robustness, be explicit about this case. Bail on get_shadow_from_swap_cache() returning NULL. -- May 17, 2024
CVE-2024-35796 In the Linux kernel, the following vulnerability has been resolved: net: ll_temac: platform_get_resource replaced by wrong function The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name. This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name)) It should have been replaced with devm_platform_ioremap_resource. -- May 17, 2024
CVE-2024-35795 In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix deadlock while reading mqd from debugfs An errant disk backup on my desktop got into debugfs and triggered the following deadlock scenario in the amdgpu debugfs files. The machine also hard-resets immediately after those lines are printed (although I wasn\'t able to reproduce that part when reading by hand): [ 1318.016074][ T1082] ====================================================== [ 1318.016607][ T1082] WARNING: possible circular locking dependency detected [ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted [ 1318.017598][ T1082] ------------------------------------------------------ [ 1318.018096][ T1082] tar/1082 is trying to acquire lock: [ 1318.018585][ T1082] ffff98c44175d6a0 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80 [ 1318.019084][ T1082] [ 1318.019084][ T1082] but task is already holding lock: [ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.020607][ T1082] [ 1318.020607][ T1082] which lock already depends on the new lock. [ 1318.020607][ T1082] [ 1318.022081][ T1082] [ 1318.022081][ T1082] the existing dependency chain (in reverse order) is: [ 1318.023083][ T1082] [ 1318.023083][ T1082] -> #2 (reservation_ww_class_mutex){+.+.}-{3:3}: [ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0 [ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90 [ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330 [ 1318.025683][ T1082] do_one_initcall+0x6a/0x350 [ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.026728][ T1082] kernel_init+0x15/0x1a0 [ 1318.027242][ T1082] ret_from_fork+0x2c/0x40 [ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.028281][ T1082] [ 1318.028281][ T1082] -> #1 (reservation_ww_class_acquire){+.+.}-{0:0}: [ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330 [ 1318.029790][ T1082] do_one_initcall+0x6a/0x350 [ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.030722][ T1082] kernel_init+0x15/0x1a0 [ 1318.031168][ T1082] ret_from_fork+0x2c/0x40 [ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.032011][ T1082] [ 1318.032011][ T1082] -> #0 (&mm->mmap_lock){++++}-{3:3}: [ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680 [ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0 [ 1318.033487][ T1082] __might_fault+0x58/0x80 [ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu] [ 1318.034181][ T1082] full_proxy_read+0x55/0x80 [ 1318.034487][ T1082] vfs_read+0xa7/0x360 [ 1318.034788][ T1082] ksys_read+0x70/0xf0 [ 1318.035085][ T1082] do_syscall_64+0x94/0x180 [ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 1318.035664][ T1082] [ 1318.035664][ T1082] other info that might help us debug this: [ 1318.035664][ T1082] [ 1318.036487][ T1082] Chain exists of: [ 1318.036487][ T1082] &mm->mmap_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [ 1318.036487][ T1082] [ 1318.037310][ T1082] Possible unsafe locking scenario: [ 1318.037310][ T1082] [ 1318.037838][ T1082] CPU0 CPU1 [ 1318.038101][ T1082] ---- ---- [ 1318.038350][ T1082] lock(reservation_ww_class_mutex); [ 1318.038590][ T1082] lock(reservation_ww_class_acquire); [ 1318.038839][ T1082] lock(reservation_ww_class_mutex); [ 1318.039083][ T1082] rlock(&mm->mmap_lock); [ 1318.039328][ T1082] [ 1318.039328][ T1082] *** DEADLOCK *** [ 1318.039328][ T1082] [ 1318.040029][ T1082] 1 lock held by tar/1082: [ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.040560][ T1082] [ 1318.040560][ T1082] stack backtrace: [ ---truncated--- -- May 17, 2024
CVE-2024-35794 In the Linux kernel, the following vulnerability has been resolved: dm-raid: really frozen sync_thread during suspend 1) commit f52f5c71f3d4 (md: fix stopping sync thread) remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn\'t realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes(). 2) The flag MD_RECOVERY_FROZEN doesn\'t mean that sync thread is frozen, it only prevent new sync_thread to start, and it can\'t stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used. 3) The flag MD_RECOVERY_FROZEN doesn\'t mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn\'t look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend(). 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend. Note that after commit f52f5c71f3d4 (md: fix stopping sync thread), the test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(), and with previous fixes, the test won\'t hang there anymore, however, the test will still fail and complain that ext4 is corrupted. And with this patch, the test won\'t hang due to stop_sync_thread() or fail due to ext4 is corrupted anymore. However, there is still a deadlock related to dm-raid456 that will be fixed in following patches. -- May 17, 2024
CVE-2024-35793 In the Linux kernel, the following vulnerability has been resolved: debugfs: fix wait/cancellation handling during remove Ben Greear further reports deadlocks during concurrent debugfs remove while files are being accessed, even though the code in question now uses debugfs cancellations. Turns out that despite all the review on the locking, we missed completely that the logic is wrong: if the refcount hits zero we can finish (and need not wait for the completion), but if it doesn\'t we have to trigger all the cancellations. As written, we can _never_ get into the loop triggering the cancellations. Fix this, and explain it better while at it. -- May 17, 2024
CVE-2024-35792 In the Linux kernel, the following vulnerability has been resolved: crypto: rk3288 - Fix use after free in unprepare The unprepare call must be carried out before the finalize call as the latter can free the request. -- May 17, 2024
CVE-2024-35791 In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() Do the cache flush of converted pages in svm_register_enc_region() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has __unregister_enc_region_locked() already queued up for the region. Note, the obvious alternative of using local variables doesn\'t fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed. Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory. -- May 17, 2024
CVE-2024-35790 In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: create sysfs nodes as driver\'s default device attribute group The DisplayPort driver\'s sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases. Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI. -- May 17, 2024
CVE-2024-35789 In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN\'s netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change. -- May 17, 2024
CVE-2024-35788 In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix bounds check for dcn35 DcfClocks [Why] NumFclkLevelsEnabled is used for DcfClocks bounds check instead of designated NumDcfClkLevelsEnabled. That can cause array index out-of-bounds access. [How] Use designated variable for dcn35 DcfClocks bounds check. -- May 17, 2024
CVE-2024-35787 In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix incorrect usage for sb_index Commit d7038f951828 (md-bitmap: don\'t use ->index for pages backing the bitmap file) removed page->index from bitmap code, but left wrong code logic for clustered-md. current code never set slot offset for cluster nodes, will sometimes cause crash in clustered env. Call trace (partly): md_bitmap_file_set_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_request+0x1dc/0x368 [md_mod] md_submit_bio+0x80/0xf8 [md_mod] __submit_bio+0x178/0x300 submit_bio_noacct_nocheck+0x11c/0x338 submit_bio_noacct+0x134/0x614 submit_bio+0x28/0xdc submit_bh_wbc+0x130/0x1cc submit_bh+0x1c/0x28 -- May 17, 2024
CVE-2024-35786 In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf If VM_BIND is enabled on the client the legacy submission ioctl can\'t be used, however if a client tries to do so regardless it will return an error. In this case the clients mutex remained unlocked leading to a deadlock inside nouveau_drm_postclose or any other nouveau ioctl call. -- May 17, 2024
CVE-2024-35785 In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix kernel panic caused by incorrect error handling The error path while failing to register devices on the TEE bus has a bug leading to kernel panic as follows: [ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c [ 15.406913] Mem abort info: [ 15.409722] ESR = 0x0000000096000005 [ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits [ 15.418814] SET = 0, FnV = 0 [ 15.421878] EA = 0, S1PTW = 0 [ 15.425031] FSC = 0x05: level 1 translation fault [ 15.429922] Data abort info: [ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000 [ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000 [ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Commit 7269cba53d90 (tee: optee: Fix supplicant based device enumeration) lead to the introduction of this bug. So fix it appropriately. -- May 17, 2024
CVE-2024-35784 In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock with fiemap and extent locking While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don\'t have lockdep annotations with the extent locking so we\'ve never noticed it. Since we\'re copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap\'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don\'t take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we\'re searching the tree, so if an ordered extent updates in the middle of our fiemap call we\'ll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we\'re checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase. -- May 17, 2024
CVE-2024-35782 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in Codeless Cowidgets – Elementor Addons allows Stored XSS.This issue affects Cowidgets – Elementor Addons: from n/a through 1.1.1. -- Jun 4, 2024
CVE-2024-35780 Deserialization of Untrusted Data vulnerability in Live Composer Team Page Builder: Live Composer.This issue affects Page Builder: Live Composer: from n/a through 1.5.42. -- Jun 20, 2024
CVE-2024-35765 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in Wpsoul Greenshift – animation and page builder blocks allows Stored XSS.This issue affects Greenshift – animation and page builder blocks: from n/a through 8.8.9.1. -- Jun 20, 2024
CVE-2024-35756 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in CeiKay Tooltip CK tooltip-ck allows Stored XSS.This issue affects Tooltip CK: from n/a through 2.2.15. -- Jun 10, 2024
CVE-2024-35755 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in El tiempo Weather Widget Pro allows Stored XSS.This issue affects Weather Widget Pro: from n/a through 1.1.40. -- Jun 10, 2024
CVE-2024-35754 Improper Limitation of a Pathname to a Restricted Directory (\'Path Traversal\') vulnerability in Ovic Team Ovic Importer allows Path Traversal.This issue affects Ovic Importer: from n/a through 1.6.3. -- Jun 12, 2024
CVE-2024-35753 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in TemplatesNext TemplatesNext OnePager allows Stored XSS.This issue affects TemplatesNext OnePager: from n/a through 1.3.3. -- Jun 10, 2024
CVE-2024-35752 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in Enea Overclokk Stellissimo Text Box allows Stored XSS.This issue affects Stellissimo Text Box: from n/a through 1.1.4. -- Jun 10, 2024
CVE-2024-35751 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in Creative Motion, Will Bontrager Software, LLC Woody ad snippets allows Stored XSS.This issue affects Woody ad snippets: from n/a through 2.4.10. -- Jun 10, 2024
CVE-2024-35750 Improper Neutralization of Special Elements used in an SQL Command (\'SQL Injection\') vulnerability in wpdevart Responsive Image Gallery, Gallery Album.This issue affects Responsive Image Gallery, Gallery Album: from n/a through 2.0.3. -- Jun 10, 2024
CVE-2024-35749 Authentication Bypass by Spoofing vulnerability in Acurax Under Construction / Maintenance Mode from Acurax allows Authentication Bypass.This issue affects Under Construction / Maintenance Mode from Acurax: from n/a through 2.6. -- Jun 12, 2024
CVE-2024-35748 Missing Authorization vulnerability in OPMC WooCommerce Dropshipping.This issue affects WooCommerce Dropshipping: from n/a through 5.0.4. -- Jun 12, 2024
CVE-2024-35747 Improper Restriction of Excessive Authentication Attempts vulnerability in wpdevart Contact Form Builder, Contact Widget allows Functionality Bypass.This issue affects Contact Form Builder, Contact Widget: from n/a through 2.1.7. -- Jun 12, 2024
CVE-2024-35746 Unrestricted Upload of File with Dangerous Type vulnerability in Asghar Hatampoor BuddyPress Cover allows Code Injection.This issue affects BuddyPress Cover: from n/a through 2.1.4.2. -- Jun 12, 2024
CVE-2024-35745 Improper Limitation of a Pathname to a Restricted Directory (\'Path Traversal\') vulnerability in Gabriel Somoza / Joseph Fitzgibbons Strategery Migrations allows Path Traversal, File Manipulation.This issue affects Strategery Migrations: from n/a through 1.0. -- Jun 12, 2024
CVE-2024-35744 Improper Limitation of a Pathname to a Restricted Directory (\'Path Traversal\') vulnerability in Ravidhu Dissanayake Upunzipper allows Path Traversal, File Manipulation.This issue affects Upunzipper: from n/a through 1.0.0. -- Jun 12, 2024
CVE-2024-35743 Improper Limitation of a Pathname to a Restricted Directory (\'Path Traversal\') vulnerability in Siteclean SC filechecker allows Path Traversal, File Manipulation.This issue affects SC filechecker: from n/a through 0.6. -- Jun 12, 2024
CVE-2024-35742 Missing Authorization vulnerability in Code Parrots Easy Forms for Mailchimp.This issue affects Easy Forms for Mailchimp: from n/a through 6.9.0. -- Jun 12, 2024
CVE-2024-35741 Missing Authorization vulnerability in Awesome Support Team Awesome Support.This issue affects Awesome Support: from n/a through 6.1.7. -- Jun 12, 2024
CVE-2024-35740 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in Theme Freesia Pixgraphy allows Stored XSS.This issue affects Pixgraphy: from n/a through 1.3.8. -- Jun 10, 2024
CVE-2024-35739 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in RadiusTheme The Post Grid allows Stored XSS.This issue affects The Post Grid: from n/a through 7.7.1. -- Jun 10, 2024
CVE-2024-35738 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in Kognetiks Kognetiks Chatbot for WordPress allows Stored XSS.This issue affects Kognetiks Chatbot for WordPress: from n/a through 1.9.8. -- Jun 10, 2024
CVE-2024-35737 Improper Neutralization of Input During Web Page Generation (XSS or \'Cross-site Scripting\') vulnerability in Loopus WP Visitors Tracker allows Reflected XSS.This issue affects WP Visitors Tracker: from n/a through 2.3. -- Jun 10, 2024
CVE-2024-35736 Improper Neutralization of Special Elements used in an SQL Command (\'SQL Injection\') vulnerability in Themeisle Visualizer.This issue affects Visualizer: from n/a through 3.11.1. -- Jun 10, 2024
The 'Fixed Release' column is displayed if a single product version is selected from the filter. The fixed release is applicable in cases when the CVE has been addressed and fixed for that product version. Requires LTSS - customers must have active LTSS (Long Term Security Shield) Support to receive up-to-date information about vulnerabilities that may affect legacy software. Please contact your Wind River account team or see https://docs.windriver.com/bundle/Support_and_Maintenance_Supplemental_Terms_and_Conditions and https://support2.windriver.com/index.php?page=plc for more information.
Live chat
Online