| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved
amdgpu_bo_create_reserved() only allocates a new BO when
*bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is
NULL, it simply skips creation when *bo_ptr is non-NULL.
But it unconditionally reserves, pins, gart allocates
and maps the BO afterwards.
When the same non-NULL BO pointer is passed in again,
for example firmware buffers that live in adev and are
re-loaded on every resume / cp_resume / start
under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases
pin_count unconditionally, however the matching teardown only unpins
once, so pin_count never drops to zero, so TTM is not able
to move, swap or evict a BO, causing BO leaks.
This commit fixes this issue by only pinning the bo
once at creation, and repeated calls no longer
take additional pin references.
(cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Account for NULL and handle pages in ttm_pool_backup
Pages in ttm_pool_backup can be NULL or backup handles
(ttm_backup_page_ptr_is_handle()), neither of which can be passed to
set_pages_array_wb() or freed. Add a dedicated WB pass before the
dma/purge loop that walks allocations using the same i += num_pages
stride, skipping NULL and handle entries, and calls set_pages_array_wb()
once per contiguous run of real pages. Apply the same NULL/handle guard
to the dma/purge loop.
Fixes the following oops:
Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI
RIP: 0010:__cpa_process_fault+0xf8/0x770
RSP: 0018:ffffc90000a87718 EFLAGS: 00010287
RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000
RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34
RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0
R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000
R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0
FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0
PKRU: 55555554
Call Trace:
<TASK>
__change_page_attr_set_clr+0x989/0xe90
? __purge_vmap_area_lazy+0x6c/0x3a0
? _vm_unmap_aliases+0x250/0x2a0
set_pages_array_wb+0x7f/0x120
ttm_pool_backup+0x4c9/0x5b0 [ttm]
? dma_resv_wait_timeout+0x3b/0xf0
ttm_tt_backup+0x32/0x60 [ttm]
ttm_bo_shrink+0x66/0x110 [ttm]
xe_bo_shrink_purge+0x12b/0x1b0 [xe]
xe_bo_shrink+0xbb/0x270 [xe]
__xe_shrinker_walk+0xf7/0x160 [xe]
xe_shrinker_walk+0x9d/0xc0 [xe]
xe_shrinker_scan+0x11f/0x210 [xe]
do_shrink_slab+0x13b/0x270
shrink_slab+0xf1/0x400
shrink_node+0x352/0x8a0
balance_pgdat+0x32c/0x700
kswapd+0x205/0x2f0
? __pfx_autoremove_wake_function+0x10/0x10
? __pfx_kswapd+0x10/0x10
kthread+0xd1/0x110
? __pfx_kthread+0x10/0x10
ret_from_fork+0x1b1/0x200
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: fix 32-bit overflow in CWSR total size calculation
total_cwsr_size was computed in 32-bit before being used as a BO/SVM
allocation size.
With large ctx_save_restore_area_size and debug_memory_size
multiplied by the XCC count, the product can wrap,
yielding an undersized CWSR save area that firmware later overruns.
Promote total_cwsr_size to u64 and use check_add_overflow()/
check_mul_overflow() in both kfd_queue_acquire_buffers() and
kfd_queue_release_buffers().
(cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Check bounds on CRIU restore queue type and mqd size
We weren't checking whether the values provided in the private
data in kfd CRIU restore were within bounds.
For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided
type is less than it.
For mqd_size, add new function mqd_size_from_queue_type and confirm
that the provided mqd_size matches expectations.
(cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Check bounds in allocate_event_notification_slot
The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT
allocate_event_notification_slot has an option to specify
an event id to allocate at, used by CRIU. We weren't checking
the bounds on that value.
Check them.
v2: Lower bounds check is unecessary because of idr_alloc
already rejecting negative numbers. Upper bounds check should
be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might
not yet exist
(cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM
The drm gpuvm code doesn't protect find operation against map operation,
and the driver needs to ensure a map operation shouldn't happen when a
find operation is in progress.
In some cases a find operation will be in progress when doing map/unmap
operations, and the find operation will do a NULL pointer dereference.
An example of the stack trace of such NULL dereference is shown below:
```
Unable to handle kernel access to user memory without uaccess routines at
virtual address 0000000000000010
[<ffffffff01e989d4>] drm_gpuva_find+0x28/0x6c [drm_gpuvm]
[<ffffffff01ed3a40>] pvr_vm_unmap+0x34/0x68 [powervr]
[<ffffffff01ec69da>] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr]
[<ffffffff8080ce0a>] drm_ioctl_kernel+0x8e/0xdc
[<ffffffff8080d016>] drm_ioctl+0x1be/0x3e0
[<ffffffff802bec3e>] __riscv_sys_ioctl+0xba/0xc4
[<ffffffff80d858b2>] do_trap_ecall_u+0x23e/0x3f4
[<ffffffff80d92288>] handle_exception+0x168/0x174
```
As all occurences of drm_gpuva_find*() are already guarded by
vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent
disturbing any find operation. This fixes the NULL deference problem in
drm_gpuva_find*(). |
| The LWS Optimize WordPress plugin before 4.1.2 does not properly escape a value submitted through an unauthenticated analytics endpoint before storing it and rendering it in an administrative dashboard, allowing unauthenticated attackers to inject arbitrary web scripts that execute when an administrator views the affected dashboard page. |
| The WP MAPS PRO WordPress plugin before 6.1.3 does not perform a capability check in one of its AJAX actions, which is also available to unauthenticated users, and does not restrict the operation it dispatches, allowing unauthenticated attackers to trigger uncontrolled recursion that exhausts server resources, resulting in a Denial of Service. |
| An Out-of-bounds Write vulnerability in WatchGuard Fireware OS's CLI could allow an authenticated privileged user to execute arbitrary code via a specially crafted CLI command. |
| An Out-of-bounds Write vulnerability in WatchGuard Fireware OS networkd process could allow an authenticated privileged user to execute arbitrary code via a specially crafted requests to the Management Web UI. |
| A path traversal vulnerability in the WatchGuard Fireware OS Management Web UI allows a privileged authenticated attacker to write arbitrary files on the Firebox's filesystem. |
| The JetEngine WordPress plugin before 3.8.13.1 does not sanitise uploaded SVG files before storing and serving them, and does not adequately restrict who can upload them, allowing unauthenticated attackers to upload a file containing malicious JavaScript that executes in the browser of any user who opens it (Stored Cross-Site Scripting). |
| The Login & Register Forms WordPress plugin before 4.0.2 does not verify that a password reset request comes from the account's owner, and does not adequately redact the address returned in its response, allowing unauthenticated users to obtain registered users' email addresses, including administrators'. |
| The Saitama Addon Pack WordPress plugin through 1.0.8 does not sanitise and escape certain post metadata values before outputting them, allowing users with contributor-level access and above to inject stored Cross-Site Scripting payloads that execute in the browser of a higher-privileged user who reviews the content. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/super: fix emergency thaw double-unlock of s_umount
do_thaw_all() iterates over all superblocks via __iterate_supers()
with SUPER_ITER_EXCL, which acquires s_umount exclusively before
calling the callback and releases it afterwards. However, the
callback do_thaw_all_callback() calls thaw_super_locked() which
unconditionally releases s_umount on every code path. This results
in a second unlock attempt in __iterate_supers() that corrupts the
rwsem state, triggering a DEBUG_RWSEMS warning:
[ 182.601148] sysrq: Emergency Thaw of all frozen filesystems
[ 182.601865] ------------[ cut here ]------------
[ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty
[ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53
[ 182.604578] Modules linked in:
[ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy)
[ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014
[ 182.606417] Workqueue: events do_thaw_all
[ 182.606750] RIP: 0010:up_write+0xaf/0x170
[ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d
[ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246
[ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870
[ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10
[ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80
[ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000
[ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800
[ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000
[ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0
[ 182.613722] Call Trace:
[ 182.613946] <TASK>
[ 182.614130] __iterate_supers+0x128/0x150
[ 182.614463] do_thaw_all+0x1b/0x30
[ 182.614759] process_scheduled_works+0xbb/0x3f0
[ 182.615150] ? __pfx_worker_thread+0x10/0x10
[ 182.615499] worker_thread+0x129/0x270
[ 182.615816] ? __pfx_worker_thread+0x10/0x10
[ 182.616201] kthread+0xe2/0x120
[ 182.616469] ? __pfx_kthread+0x10/0x10
[ 182.616792] ret_from_fork+0x15b/0x240
[ 182.617115] ? __pfx_kthread+0x10/0x10
[ 182.617426] ret_from_fork_asm+0x1a/0x30
[ 182.617761] </TASK>
[ 182.617968] ---[ end trace 0000000000000000 ]---
[ 182.618412] Emergency Thaw complete
Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount
in the callback via super_lock_excl() before calling
thaw_super_locked(). This matches the locking pattern expected by
thaw_super_locked() and eliminates the double unlock.
While at it, remove the dead 'return;' at the end of
do_thaw_all_callback(). |
| In the Linux kernel, the following vulnerability has been resolved:
libceph: remove debugfs files before client teardown
ceph_destroy_client() tears down the monitor client before removing
the per-client debugfs files. A concurrent read of the monmap debugfs
file can enter monmap_show() after ceph_monc_stop() has freed
monc->monmap, triggering a use-after-free.
Remove the debugfs files before stopping the OSD and monitor clients.
debugfs_remove() drains active handlers and prevents new accesses, so
the debugfs callbacks can no longer race the rest of client teardown. |
| In the Linux kernel, the following vulnerability has been resolved:
libceph: guard missing CRUSH type name lookup
Localized read selection can walk a parent bucket whose name exists in
the CRUSH map while its type has no matching entry in type_names.
get_immediate_parent() then dereferences a NULL type_cn and passes an
invalid pointer into strcmp(), causing a null-ptr-deref.
Skip such malformed parent buckets unless both the bucket name and type
name metadata are present. This keeps malformed hierarchy data from
crashing locality lookup and safely falls back to "not local".
[ idryomov: add WARN_ON_ONCE ] |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: close UDP tunnel sockets during netns teardown
proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when
net.sctp.udp_port is set, and stops/restarts them when the sysctl value
changes. The netns exit path does not stop these sockets, so a namespace
can be torn down while its SCTP UDP tunnel sockets are still installed.
Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering
the per-net sysctl table. This prevents new sysctl writes from racing in
while the sockets are being released, and closes the sockets before the
control socket is destroyed. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/page_vma_mapped: fix device-private PMD handling
Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support
device-private entries") introduced the concept of device-private PMD
entries, but did not correctly update the rmap walk code to account for
them.
As a result, when page_vma_mapped_walk() encounters device-private PMD
entries, it takes no action other than to acquire the PMD lock and exit.
However this is highly problematic for two reasons - firstly, device
private entries possess a PFN so check_pmd() needs to be called to ensure
an overlapping PFN range.
Secondly, and more importantly, if PVMW_MIGRATION is set the caller
assumes the returned entry is a migration entry, resulting in memory
corruption when the caller tries to interpret the device private entry as
such.
In addition, commit 146287290023 ("mm/huge_memory: implement
device-private THP splitting") allowed device private PMDs to be split
like THP mappings, but again did not update this code path.
As a result, we might race a PMD split prior to acquiring the PMD lock.
This patch addresses all of these issues by invoking check_pmd(), ensuring
PMVW_MIGRATION is not set and checks whether a split raced us we do for
PMD THP and migration entries.
Instead of checking for a subset of the cases after taking the pmd_lock(),
put device-private along with pmd_trans_huge() and
pmd_is_migration_entry(). Also remove thp_migration_supported() as it is
already guarded by pmd_is_migration_entry().
[akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David] |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: comedi_parport: deal with premature interrupt
Syzbot reported a general protection fault in
`comedi_get_is_subdevice_running()`, which was called from the interrupt
handler `parport_interrupt()` in the "comedi_parport" driver, but it
does not currently have a C reproducer for the problem. It's
probably due to a premature interrupt for one of two reasons:
1. The driver sets up the interrupt handler before the comedi subdevices
used by the interrupt handler have been allocated, but does not
disable the interrupt in the parallel port's CTRL register first.
2. The driver uses a user-supplied I/O port base address which Syzbot
would have supplied, but it might not be backed by real parallel port
hardware.
Change the initialization order in the driver's comedi "attach" handler
(`parport_attach()`) so that the hardware registers are initialized
before the interrupt handler is requested. This should prevent
premature interrupts occurring for real hardware.
Also add a test to the interrupt handler to ensure the comedi device is
fully attached and return early if it isn't. |
