| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
misc: bcm-vk: Use acquire/release for msgq_inited
bcm_vk_sync_msgq() fills the message queue information and then sets
msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the
message queues and their cached queue information.
atomic_set()/atomic_read() do not order those accesses. A reader can see
msgq_inited set while still seeing stale queue information. Use release
when publishing the initialized queues and acquire when checking the gate.
Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the
gate and does not publish queue state to readers. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context
TX EQTR may run while devfreq gear scaling has quiesced the UFS
tagset. In that context, functions ufshcd_tx_eqtr(), __ufshcd_tx_eqtr()
and ufs_qcom_get_rx_fom() allocate memory with GFP_KERNEL. If direct
reclaim is triggered, reclaim/writeback can depend on I/O to UFS
device. Because the queue is quiesced, this can cause deadlock.
Use memalloc_noio_save/restore() in ufshcd_tx_eqtr() to cover all
allocations in the TX EQTR call tree, including:
- params->eqtr_record in ufshcd_tx_eqtr()
- eqtr_data in __ufshcd_tx_eqtr()
- params in ufs_qcom_get_rx_fom()
This is preferred over tagging individual call sites with GFP_NOIO, as it
automatically covers any future allocations added anywhere in the call tree
without requiring each caller to be aware of this constraint.
[mkp: fix label as suggested by Bart] |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragments
Make sure we don't end-up with a num_frags = 0 situation.
For that, check that the required size is not 0 and put a checker on
num_frags as well. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser
iwl_mvm_frob_txf_key_iter() tracks the last matched byte position
in loop variable 'i'. When a full key match is found (match ==
keylen), 'i' points at the last byte of the matched key. The
memset start offset should therefore be i + 1 - keylen, not
i - keylen; the current code zeroes one byte before the match
and leaves the final key byte un-sanitised. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-wmi-base: Fix resource leak on module load failure
We need to properly clean up the SMBIOS request and the privacy driver
when the module load fails. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix use-after-free on mm_struct in bpf_find_vma()
bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without
holding a reference on the mm. On a foreign task, a concurrent exit_mm()
can free the mm_struct between the lockless read and the trylock,
resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU.
For the current task, task->mm is stable. For a foreign task, pin the mm
under task->alloc_lock and release it with mmput_async(), mirroring commit
d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded task_vma iterator").
Use spin_trylock() instead of get_task_mm() so BPF context does not block
on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the
foreign-task path because dropping the mm reference is not safe there.
Race:
CPU0 (BPF program) CPU1 (exiting task)
============================ ==========================
bpf_find_vma(foreign_task):
mm = task->mm
exit_mm():
task->mm = NULL
mmput(mm) -> frees mm_struct
mmap_read_trylock(mm)
// UAF on mm |
| In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/rcar: Fix error checking in probe()
This code accidentally calls thermal_zone_device_enable() before checking
whether thermal_zone_device_register_with_trips() failed. Move the call
until later to avoid an error pointer dereference of "priv->zone".
The driver works differently depending on if we are using OF thermal or
not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and
call thermal_zone_device_enable() if not. We can share same error check
for if either of these fail.
Moving the thermal_zone_device_enable() call is a bit cleaner as well.
The original code used a three step process to cleanup:
1. Call thermal_zone_device_unregister() to cleanup.
2. Set priv->zone to an error pointer to preserve the error code.
3. Set priv->zone to NULL to avoid a second call to
thermal_zone_device_unregister() in the rcar_thermal_remove()
function.
Now we can just do a direct goto error_unregister and rcar_thermal_remove()
handles the cleanup properly. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject writes through untrusted BTF pointers
check_ptr_to_btf_access() lets program-type btf_struct_access callbacks
validate writes before the default BTF access path rejects non-read
accesses. That bypasses the read-only policy for untrusted BTF pointers
created by helpers such as bpf_rdonly_cast().
Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the
common entry point, before the callback branch to handle all cases. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet-rdma: fix response resource leak on queue teardown
When an nvme target with rdma transport is removed while I/Os are in
flight, a response can be posted but its send completion is never
delivered before the connection is torn down. As a result
nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for
the response, and this leaks the allocated RDMA read/write context and
request SGLs.
These leaks are recreated by running blktests nvme/061 with the rdma
transport and the siw driver. Kernel kmemleak feature reports them as
follows:
unreferenced object 0xffff88812bc490c0 (size 32):
comm "kworker/2:1H", pid 409, jiffies 4307744490
backtrace (crc 89afd339):
__kmalloc_noprof+0x5f9/0x890
sgl_alloc_order+0x7b/0x380
nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet]
nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma]
nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma]
__ib_process_cq+0x149/0x4c0 [ib_core]
ib_cq_poll_work+0x49/0x160 [ib_core]
process_one_work+0x8b2/0x1640
worker_thread+0x5fd/0xfe0
kthread+0x367/0x460
ret_from_fork+0x655/0x9d0
ret_from_fork_asm+0x1a/0x30
unreferenced object 0xffff88814bd05e80 (size 64):
comm "kworker/3:1H", pid 148, jiffies 4295195428
backtrace (crc e35510cb):
__kmalloc_noprof+0x5f9/0x890
rdma_rw_ctx_init+0x333/0x1fa0 [ib_core]
nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma]
nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma]
__ib_process_cq+0x149/0x4c0 [ib_core]
ib_cq_poll_work+0x49/0x160 [ib_core]
process_one_work+0x8b2/0x1640
worker_thread+0x5fd/0xfe0
kthread+0x367/0x460
ret_from_fork+0x655/0x9d0
ret_from_fork_asm+0x1a/0x30
To avoid the memory leaks, reclaim the memory of the in-flight responses
when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources()
that frees up the RDMA read/write context and the request SGLs of such
responses. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: keembay - Fix AEAD unregister count in error path
register_aes_algs() registers the AEAD algorithms before registering the
skcipher algorithms. If skcipher registration fails, the function unwinds
the earlier AEAD registration with crypto_engine_unregister_aeads(), but it
passes ARRAY_SIZE(algs), which is the skcipher table size.
Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper
iterates over the same table that was registered. Also clarify the nearby
comment: the crypto registration helpers clean up algorithms registered
within the same call, while this function must still unwind earlier
successful registration steps. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc4-topology: Return error for invalid number of formats
When the number of input or output formats is zero,
sof_ipc4_widget_setup_comp_src() and sof_ipc4_widget_setup_comp_asrc()
print an error and jump to the cleanup label. At that point 'ret' is
still 0, because the earlier sof_ipc4_get_audio_fmt() call succeeded, so
the function returns success and the caller never finds out that the
widget setup actually failed.
Set ret to -EINVAL before the goto so the error gets reported. |
| In the Linux kernel, the following vulnerability has been resolved:
smack: fix incorrect task context in smack_msg_queue_msgrcv
The smack_msg_queue_msgrcv() function incorrectly checks
the permissions of the 'current' task instead of the
'target' task.
In the msgsnd() syscall path, if a receiver is already waiting,
the pipelined_send() optimization is used to push the message
directly to the receiver task:
ipc/msg.c`pipelined_send():
` smp_store_release(&msr->r_msg, msg)
In this case, the 'sender' (current) task performs the check
on behalf of the 'receiver' task (msr->r_tsk, passed as the
'target' parameter):
ipc/msg.c`pipelined_send():
` security_msg_queue_msgrcv(,, target := msr->r_tsk,,)
However, smack_msg_queue_msgrcv() ignores the 'target' and
checks 'current':
smack_msg_queue_msgrcv(…)
` smk_curacc_msq(isp, MAY_READWRITE); // current task
'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement,
but 'target' (the receiver task) might NOT;
as a result, an unauthorized receiver gets the message,
violating MAC policy.
Test:
1) create a sysv message queue with label “foo”
2) echo "bar foo r" >/smack/load2
3) msgrcv(,,,0,MSG_NOERROR) in "bar"-labeled task.
The task is waiting for the messages ...
4) msgsnd() from a "foo"-labeled task:
"bar"-labeled task gets the message.
This patch fixes the issue by checking permission on the
'target' task instead of 'current'.
(2008-02-04, Casey Schaufler) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Clear queue->active_job when v3d_fence_create() fails
The run_job() callbacks for BIN, RENDER, TFU and CSD assign the incoming
job to queue->active_job before calling v3d_fence_create(). If
v3d_fence_create() fails, the callback returns NULL without clearing
active_job, leaving a dangling pointer.
Create a failure path in all run_job() callbacks that clears the active
job before returning NULL. The BIN path takes queue->queue_lock around the
clear as it races against v3d_overflow_mem_work(); RENDER, TFU and CSD
paths have no concurrent reader, so the clear is lock-free. |
| The Newsletter – Send awesome emails from WordPress plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the 'nn' parameter in all versions up to, and including, 9.3.8 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link. Successful exploitation requires the victim to be a logged-in administrator, as the antibot check auto-passes for authenticated users, routing the unsanitized payload through the administrator-visible output branch of dienow(). |
| The Qi Addons For Elementor plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the 's' parameter in all versions up to, and including, 1.11 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. Exploitation requires the Table of Contents widget to be placed on a template that renders on the WordPress search-results page (e.g., a sitewide header or footer template) with the 'Limit ToC to Main Page Content' option left at its default value of No, so the widget scans the search-results heading that reflects the unsanitized `s` parameter. |
| The WP Recipe Maker plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'notes' parameter in all versions up to, and including, 10.8.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
| In the Linux kernel, the following vulnerability has been resolved:
media: ipu6: Do not free aux device pdata after init
ipu6_bus_initialize_device() stores the isys/psys pdata pointer in
struct ipu6_bus_device and initializes the auxiliary device. After that
point, error unwinding must drop the auxiliary device reference and let
ipu6_bus_release() free both the bus device and adev->pdata.
The isys and psys init paths already call put_device() when MMU
initialization fails, and ipu6_bus_add_device() calls
auxiliary_device_uninit() on auxiliary_device_add() failure. Both paths
therefore run the bus release callback. The extra kfree(pdata) in the
callers can release the same object a second time.
Remove the manual pdata frees after the auxiliary device has been
initialized.
This issue was found by a static analysis checker and confirmed by
manual source review. |
| In the Linux kernel, the following vulnerability has been resolved:
dax/fsdev: use __va(phys) for kaddr in direct_access
Use __va(phys) instead of virt_addr + linear_offset for the kaddr
return in __fsdev_dax_direct_access(). The previous code added a
device-linear byte offset to virt_addr (which is __va of ranges[0]),
but for multi-range devices with physical gaps between ranges, this
linear arithmetic crosses the gap and produces a wrong kernel virtual
address. Using __va(phys) where phys comes from dax_pgoff_to_phys()
is correct for any range layout because the direct map translates
each physical address independently.
This leaves dev_dax->virt_addr write-only, so remove the field
(suggested by Dave Jiang). |
| In the Linux kernel, the following vulnerability has been resolved:
dax/fsdev: clear pgmap ops and owner on unbind
fsdev_dax_probe() sets pgmap->ops = &fsdev_pagemap_ops and
pgmap->owner = dev_dax, but nothing ever clears them. For a dynamic
device the pgmap is devm-allocated and freed on unbind, so this is
harmless. For a static device the pgmap is the shared, long-lived one
owned by the dax bus (kill_dev_dax() only NULLs dev_dax->pgmap for the
non-static case), and device.c's probe sets only pgmap->type, never
clearing ops/owner.
So after fsdev unbinds a static device the stale fsdev_pagemap_ops
survives on the shared pgmap. If the device is then rebound to
device_dax (MEMORY_DEVICE_GENERIC, which installs no ->memory_failure),
or the fsdev_dax module is unloaded, a subsequent memory_failure on that
pgmap dispatches through the stale -- and possibly freed -- handler.
Register a devm action that clears pgmap->ops and pgmap->owner on unbind,
symmetric with setting them at probe, so the pgmap carries no fsdev state
once fsdev is detached. |
| In the Linux kernel, the following vulnerability has been resolved:
cxl/features: Clamp Get Feature output size to the remaining buffer
cxl_get_feature() reads a feature in a loop but passes a fixed size_out
as the output capacity every iteration. On the last partial iteration
the buffer has less room left, so a device that returns more than asked
can overflow feat_out.
Use the per-iter size data_to_rd_size, which already tracks the
remaining room, as the output capacity. |
