| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
hfs/hfsplus: zero-initialize buffer in hfs_bnode_read
hfs_bnode_read() can return early without writing to the output buffer
when is_bnode_offset_valid() fails or when check_and_correct_requested_
length() corrects the length to zero. Callers such as hfs_bnode_read_
u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the
result unconditionally, leading to KMSAN uninit-value reports.
Rather than initializing at each individual call site, zero the buffer
at the start of hfs_bnode_read() before any validation checks. This
ensures all callers in both hfs and hfsplus get a deterministic zero
value regardless of which early-return path is taken. |
| In the Linux kernel, the following vulnerability has been resolved:
cpufreq: pcc: fix use-after-free and double free in _OSC evaluation
pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the
two-phase _OSC negotiation. Between the two calls it freed
output.pointer but left output.length unchanged. Since
acpi_evaluate_object() treats a non-zero length with a non-NULL
pointer as an existing buffer to write into, the second call wrote
into freed memory (use-after-free). The subsequent kfree(output.pointer)
at out_free then freed the same pointer a second time (double free).
Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER
after freeing the first result, so ACPICA allocates a fresh buffer for
each phase independently. |
| In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT
RT migration is done aggressively. When a CPU schedules out a high
priority RT task for a lower priority task, it will look to see if there's
any RT tasks that are waiting to run on another CPU that is of higher
priority than the task this CPU is about to run. If it finds one, it will
pull that task over to the CPU and allow it to run there instead.
Normally, this pulling is done by looking at the RT overloaded mask (rto)
which contains all the CPUs in the scheduler domain with RT tasks that are
waiting to run due to a higher priority RT task currently running on their
CPU. The CPU that is about to schedule a lower priority task will grab the
rq lock of the overloaded CPU and move the RT task from that CPU's runqueue
to the local one and schedule the higher priority RT task.
This caused issues when a lot of CPUs would schedule a lower priority task
at the same time. They would all try to grab the same runqueue lock of
the CPU with the overloaded RT tasks. Only the first CPU that got in will
get that task. All the others would wait until they got the runqueue lock
and see there's nothing to pull and do nothing. On systems with lots of
CPUs, this caused a large latency (up to 500us) which is beyond what
PREEMPT_RT is to allow.
The solution to that was to create an RT_PUSH_IPI logic. When any CPU
wanted to pull a task, instead of grabbing the runqueue lock of the
overloaded CPU, it would start by sending an IPI to the overloaded CPU,
and that IPI handler would have the CPU with the waiting RT task do a push
instead. Then that handler would send an IPI to the next CPU with
overloaded RT tasks, and so on. Note, after the first CPU starts this
process, if another CPU wanted to do a pull, it would see that the process
has already begun and would only increment a counter to have the IPIs
continue again.
The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause
a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded
context on PREEMPT_RT but they can run in an interrupt context in non-RT.
If an IPI lands on a CPU that has just woken up multiple RT tasks and the
current CPU is running a non RT or a low priority RT task, instead of
doing a push, it would simply do a schedule on that CPU. But if a softirq
was also executing on this CPU, the schedule would need to wait until the
softirq finished. Until then, the CPU would still be considered overloaded
as there are RT tasks still waiting to run on it.
A live lock occurred on a workload that was doing heavy networking traffic
on a large machine where the softirqs would run 500us out of 750us. And it
would also be waking up RT tasks, causing the RT pull logic to be
constantly executed.
When a softirq triggered on a CPU with RT tasks queued but not running
yet, and the other CPUs would see this CPU as being overloaded, they would
send an IPI over to it. The CPU would notice that the waiting RT tasks are
of higher priority than the currently running task and simply schedule
that CPU instead. But because the softirq was executing, before it could
schedule, it would receive another IPI to do the same. The amount of IPIs
would slow down the currently running softirq so much that before it could
return back to task context, it would execute another softirq never
allowing the CPU to schedule. This live locked that CPU.
As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if
PREEMPT_RT is not enabled. |
| The WooCommerce PayPal Payments plugin for WordPress is vulnerable to Sensitive Information Disclosure due to an Insecure Direct Object Reference in all versions up to, and including, 3.3.2 via the `enqueue_paypal_insights_script_on_order_received()` function due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to obtain sensitive order information including order keys, which can then be leveraged to access full customer billing details (name, email, phone, address) via the WooCommerce Store API within a 10-minute grace period after order creation. |
| The Advanced Woo Labels – Product Labels & Badges for WooCommerce plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'bg_color' parameter in all versions up to, and including, 2.48 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. |
| FreeRDP before 3.29.0 contains a buffer over-disclosure vulnerability in the gateway WebSocket transport (libfreerdp/core/gateway/websocket.c). The client's Pong reply reuses a fixed 1024-byte response stream whose length is not sealed to the actual received Ping payload, so a malicious gateway/WebSocket peer sending a non-empty Ping control frame causes the client to reply with an overlong Pong that discloses bytes beyond the received payload (the peer receives the masking key and can unmask the reply). A zero-length Ping reaches an assertion and terminates the client (denial of service). |
| The Advanced Views – Display Custom Fields (ACF, Pods, MetaBox), Posts, CPT and Woo Products anywhere in Gutenberg, Elementor, Divi, Beaver… plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 3.9.1 via the register_rest_routes. This makes it possible for authenticated attackers, with subscriber-level access and above, to extract sensitive admin-authored editor content — including template markup, CSS code, JavaScript code, and PHP controller variables — for any Layout or Post Selection post on the site. |
| The Subscriptions for WooCommerce plugin for WordPress is vulnerable to Privilege Escalation in versions up to, and including, 2.0.0. This is due to the `save_meta_boxes()` function persisting the `_wps_plan_user_role` membership plan meta from `$_POST` without an allowlist that excludes privileged roles — the only validations applied, `sanitize_key()` and `wp_roles()->is_role()`, both accept `'administrator'` as a valid value, and the UI's `disabled` attribute on the role dropdown is a client-side-only control trivially bypassed via DevTools or a direct POST request; additionally, because the `wps_membership_plan` custom post type is registered with `capability_type => 'post'`, any user who can edit posts satisfies the `current_user_can('edit_post', $post_id)` guard in `save_meta_boxes()`. This makes it possible for authenticated attackers, with Contributor-level access and above, to escalate their privileges to Administrator by storing `'administrator'` as the role granted on membership acquisition, which the Pro companion plugin then applies via `add_role()` during membership lifecycle events. Successful exploitation requires the Subscriptions for WooCommerce Pro companion plugin to be active, as it is the component that reads the stored `_wps_plan_user_role` meta via `get_post_meta()` and calls `add_role()` to apply the role during membership lifecycle events. |
| The Jeg Kit for Elementor plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 3.1.1 via the `enqueue_scripts()` method in `class/dashboard/class-dashboard.php`. The plugin injects a `JkitDashboardOption` JavaScript object containing full plugin inventory (names, versions, paths, active status), system environment details (WordPress version, PHP version, site URLs, server capabilities), and potentially third-party API credentials (Mailchimp API key via `jkit_user_data`) as an inline script on the `post.php` admin page. Because this data is output without any capability check beyond post editing access, any authenticated user with Contributor-level access or above can view this sensitive configuration data by inspecting the page source. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract sensitive site configuration data, installed plugin details, and potentially third-party API keys. |
| In hevc decoder, there is a possible out of bounds write due to an integer overflow. This could lead to remote escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11104718; Issue ID: MSV-8297. |
| The Fluent Forms – Customizable Contact Forms, Survey, Quiz, & Conversational Form Builder plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via 'param' in all versions up to, and including, 6.2.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. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2_ioctl() replay
A response-bearing attempt can return a replayable error and free its
response buffer. If SMB2_ioctl_init() fails before the next send, cleanup
retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock cancellation
When a blocking byte-range lock request is deferred in the
FILE_LOCK_DEFERRED path, ksmbd registers the asynchronous work into
the connection's async_requests list via setup_async_work(). The cancel
callback smb2_remove_blocked_lock() holds a reference to the flock.
If the lock waiter is subsequently woken up but the work state is no
longer KSMBD_WORK_ACTIVE (e.g., due to a concurrent cancellation), the
cleanup path calls locks_free_lock(flock) without dequeuing the work from
the async_requests list. Concurrently, smb2_cancel() walks the list
under conn->request_lock and invokes the cancel callback, which then
dereferences the already freed 'flock'. This leads to a slab-use-after-free
inside __wake_up_common.
Fix this by restructuring the cleanup logic after the worker returns
from ksmbd_vfs_posix_lock_wait(). Move list_del(&smb_lock->llist) and
release_async_work(work) to the top of the cleanup block. This guarantees
that the async work is completely dequeued and serialized under
conn->request_lock before locks_free_lock(flock) is called, rendering
the flock unreachable for any concurrent smb2_cancel(). |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
Every once in a while we see a hung btmtksdio_flush() task:
INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
__cancel_work_timer+0x3f4/0x460
cancel_work_sync+0x1c/0x2c
btmtksdio_flush+0x2c/0x40
hci_dev_open_sync+0x10c4/0x2190
[..]
It all boils down to incorrect time_is_before_jiffies() usage in
btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected
to be terminated if running for longer than 5*HZ. However the
timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ)
evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a
timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout)
means that:
- before the 5-second timeout: the condition is `int_status || false`,
so it loops as long as there are pending interrupts.
- after the 5-second timeout: the condition becomes `int_status || true`,
which is always true.
When the loop becomes infinite btmtksdio_txrx_work() loop never
terminates and never releases the SDIO host.
Fix loop termination condition to actually enforce a 5*HZ timeout. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: module names must be null-terminated
We need to explicitly check the length, else we may pass non-null
terminated string to request_module(). |
| In the Linux kernel, the following vulnerability has been resolved:
mm: shrinker: fix NULL pointer dereference in debugfs
shrinker_debugfs_add() creates both "count" and "scan" debugfs files
unconditionally.
That assumes every shrinker implements both count_objects() and
scan_objects(), which is not guaranteed. For example, the xen-backend
shrinker sets count_objects() but leaves scan_objects() NULL, so writing
to its scan file calls through a NULL function pointer and panics the
kernel:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
Call Trace:
<TASK>
shrinker_debugfs_scan_write+0x12e/0x270
full_proxy_write+0x5f/0x90
vfs_write+0xde/0x420
? filp_flush+0x75/0x90
? filp_close+0x1d/0x30
? do_dup2+0xb8/0x120
ksys_write+0x68/0xf0
? filp_flush+0x75/0x90
do_syscall_64+0xb3/0x5b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The count path has the same issue in principle if a shrinker omits
count_objects().
To fix it, only create "count" and "scan" debugfs files when the
corresponding callbacks are present. |
| In the Linux kernel, the following vulnerability has been resolved:
mfd: cros_ec: Delay dev_set_drvdata() until probe success
If ec_device_probe() fails, cros_ec_class_release releases memory for the
cros_ec_dev structure. However, because the drvdata was already set,
sub-drivers like cros_ec_typec can still retrieve the stale pointer via the
platform device. This leads to a use-after-free when cros_ec_typec attempts
to access &typec->ec->ec->dev on a device that has already been released.
Move dev_set_drvdata() to ensure that the pointer is only made available
once all initialization steps have succeeded.
sysfs: cannot create duplicate filename '/class/chromeos/cros_ec'
Call trace:
sysfs_do_create_link_sd+0x94/0xdc
sysfs_create_link+0x30/0x44
device_add_class_symlinks+0x90/0x13c
device_add+0xf0/0x50c
ec_device_probe+0x150/0x4f0
platform_probe+0xa0/0xe0
...
BUG: KASAN: invalid-access in __memcpy+0x44/0x230
Write at addr f5ffff809e2d33ac by task kworker/u32:5/125
Pointer tag: [f5], memory tag: [fe]
Tainted : [W]=WARN, [O]=OOT_MODULE
Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3
Workqueue: events_unbound deferred_probe_work_func
Call trace:
__memcpy+0x44/0x230
cros_ec_check_features+0x60/0xcc [cros_ec_proto]
cros_typec_probe+0xe8/0x6e0 [cros_ec_typec]
platform_probe+0xa0/0xe0 |
| In the Linux kernel, the following vulnerability has been resolved:
media: nxp: imx8-isi: Fix use-after-free on remove
KASAN reports a slab-use-after-free in __media_entity_remove_link()
during rmmod of imx8_isi:
BUG: KASAN: slab-use-after-free in __media_entity_remove_link+0x608/0x650
Read of size 2 at addr ffff0000d47cb02a by task rmmod/724
Call trace:
__media_entity_remove_link+0x608/0x650
__media_entity_remove_links+0x78/0x144
__media_device_unregister_entity+0x150/0x280
media_device_unregister_entity+0x48/0x68
v4l2_device_unregister_subdev+0x158/0x300
v4l2_async_unbind_subdev_one+0x22c/0x358
v4l2_async_nf_unbind_all_subdevs+0xfc/0x1c0
v4l2_async_nf_unregister+0x5c/0x14c
mxc_isi_remove+0x124/0x2a0 [imx8_isi]
Allocated by task 249:
__kmalloc_noprof+0x27c/0x690
mxc_isi_crossbar_init+0x22c/0x560 [imx8_isi]
Freed by task 724:
kfree+0x1e4/0x5b0
mxc_isi_crossbar_cleanup+0x34/0x80 [imx8_isi]
mxc_isi_remove+0x11c/0x2a0 [imx8_isi]
The problem is that mxc_isi_remove() calls mxc_isi_crossbar_cleanup()
before mxc_isi_v4l2_cleanup(). The crossbar cleanup frees the media
entity pads, but the subsequent v4l2 cleanup still tries to remove
media links that reference those pads.
Fix this by calling mxc_isi_v4l2_cleanup() before
mxc_isi_crossbar_cleanup() to ensure all media entities are properly
unregistered while the pads are still valid. |
| In the Linux kernel, the following vulnerability has been resolved:
ipv4: igmp: remove multicast group from hash table on device destruction
When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through
the multicast list and calls ip_ma_put() on each membership, scheduling
them for RCU reclamation. However, they are not unlinked from the device's
multicast hash table (mc_hash).
Since the device remains published in dev->ip_ptr until after
ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash
can still locate and access the multicast group after its refcount is
decremented. If the RCU callback runs and frees the group while a reader is
accessing it, a use-after-free occurs.
Fix this by unlinking the multicast group from mc_hash using
ip_mc_hash_remove() before scheduling it for reclamation.
BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0
Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276
Call Trace:
<IRQ>
dump_stack_lvl+0x67/0x90
print_report+0x175/0x7c0
kasan_report+0x147/0x180
ip_check_mc_rcu+0x149/0x3f0
udp_v4_early_demux+0x36d/0x12d0
ip_rcv_finish_core+0xb8b/0x1390
ip_rcv_finish+0x54/0x120
NF_HOOK+0x213/0x2b0
__netif_receive_skb+0x126/0x340
process_backlog+0x4f2/0xf00
__napi_poll+0x92/0x2c0
net_rx_action+0x583/0xc60
handle_softirqs+0x236/0x7f0
do_softirq+0x57/0x80
</IRQ>
Allocated by task 2239:
kasan_save_track+0x3e/0x80
__kasan_kmalloc+0x72/0x90
____ip_mc_inc_group+0x31a/0xa40
__ip_mc_join_group+0x334/0x3f0
do_ip_setsockopt+0x16fa/0x2010
ip_setsockopt+0x3f/0x90
do_sock_setsockopt+0x1ad/0x300
Freed by task 0:
kasan_save_track+0x3e/0x80
kasan_save_free_info+0x40/0x50
__kasan_slab_free+0x3a/0x60
__rcu_free_sheaf_prepare+0xd4/0x220
rcu_free_sheaf+0x36/0x190
rcu_core+0x8d9/0x12f0
handle_softirqs+0x236/0x7f0 |
| PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Prior to 8.5.19, if from is unset, an attacker can cause PreviousMap.loadFile() to read an unintended source-map file by supplying an absolute or directory-traversal sourceMappingURL. The resulting map’s sources and sourcesContent may then be exposed to the application. This issue is fixed in version 8.5.19. |
