| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Missing authentication for critical function in Windows SmartScreen allows an authorized attacker to perform tampering locally. |
| Use after free in Remote Desktop Client allows an unauthorized attacker to execute code over a network. |
| Use after free in Remote Desktop Client allows an unauthorized attacker to execute code over a network. |
| Heap-based buffer overflow in Microsoft Office allows an unauthorized attacker to execute code over a network. |
| Stack-based buffer overflow in Microsoft Office Word allows an unauthorized attacker to execute code over a network. |
| Use after free in Media in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Low) |
| Improper input validation in ANGLE in Google Chrome on on Mac prior to 156.0.8078.47 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Use after free in Network in Google Chrome on on Windows prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Memory corruption in ContextMenu in Google Chrome on on Android prior to 156.0.8078.47 allowed a remote attacker to potentially execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Low) |
| Memory corruption in ANGLE in Google Chrome on on Windows prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Fallow is a codebase intelligence tool for TypeScript and JavaScript. From 2.68.0 until 3.34.0, Fallow follows attacker-controlled Jest projects paths outside the project root through absolute paths, parent segments, dot-prefixed wildcard globs, or symlinks. In version 3.33.1, the same behavior also affects Vitest test.projects paths, Vitest inline-project extends paths, and symlinked script --config paths. Fallow parses the outside files as test-runner configuration and uses them to credit dependencies, setup files, and JSX import sources, which can change unused dependency and unused file findings in CI or agent analysis. The outside file contents are not printed or sent over the network. This issue is fixed in version 3.34.0. |
| An issue in @rog0x/mcp-docker-tools 1.0.1 allows a remote attacker to execute arbitrary code via the handleImageList function. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: io: Reject non-user protection in ioremap_prot()
Mapping a stack-top page via /dev/mem with PROT_NONE and then
reading that process's /proc/<pid>/cmdline triggers a spurious WARN
in ioremap_prot() through generic_access_phys():
WARNING: ./arch/arm64/include/asm/io.h:275 at generic_access_phys
Call trace:
generic_access_phys+0x1c8/0x228 (P)
__access_remote_vm+0x2b4/0x398
access_remote_vm+0x14/0x30
get_mm_cmdline+0xf8/0x2a0
proc_pid_cmdline_read+0x68/0x120
generic_access_phys() passes the protection derived from the user PTE
to ioremap_prot(). On arm64, a PROT_NONE mapping is represented by a
present-invalid PTE, so pte_present() still returns true and the
protection reaches ioremap_prot().
A PROT_NONE mapping does not have PTE_USER, causing the existing
WARN_ON_ONCE() in ioremap_prot() to fire even though this is a valid
user mapping. Execute-only mappings have the same issue and must not
be readable through this path either.
ioremap_prot() should therefore reject protection values without
PTE_USER without warning. This makes the access fail cleanly for
PROT_NONE and execute-only mappings while retaining the existing
user-protection contract. |
| In the Linux kernel, the following vulnerability has been resolved:
fs: avoid repeated scans in evict_inodes()
We observed hung tasks when users attempted to unmount a filesystem
after its disk had been removed while still in use. During device
removal, fs_bdev_mark_dead() calls evict_inodes() while holding s_umount.
Each time evict_inodes() drops s_inode_list_lock to reschedule, it
restarts the walk from the head of s_inodes. With many referenced inodes
at the head of the list, these restarts repeatedly scan the same inodes
without reclaiming them. This can keep s_umount held for a long time,
blocking concurrent umount attempts and triggering hung-task reports.
Keep the current inode, already marked I_FREEING, out of the disposal
batch until s_inode_list_lock is reacquired. Resume the walk from this
inode and dispose of it in a later batch or at the end of the walk.
The zero-refcount and state checks under i_lock allow this walker to
claim the inode by setting I_FREEING and removing it from the LRU.
Other reclaimers skip the inode, leaving this walker responsible for
eviction. Only evict() removes it from s_inodes, so keeping it out of
the disposal batch ensures that it remains on the list while the lock
is dropped. After reacquiring the lock, reading its current next pointer
accounts for concurrent removal of following inodes.
The existing inode lifetime rules prohibit acquiring a reference to an
inode marked I_FREEING or I_WILL_FREE. __iget() requires its caller to
hold i_lock and establish that taking a reference is valid. Inode lookup
and igrab() check these flags under i_lock when acquiring a reference
from zero. ihold() requires an existing reference, which would keep
i_count nonzero and prevent this walker from claiming the inode. These
rules already allow iput_final() and the inode shrinker to release
i_lock after setting I_FREEING and before eviction completes.
A temporary __iget() reference would also keep the inode on the list,
but its release must preserve last-reference handling. Another user can
acquire a reference, update lazy timestamps and drop its reference while
the pin is held. If the pin becomes the last reference, dropping it with
atomic_dec_and_test() and evicting directly bypasses iput()'s lazytime
handling and can lose those timestamp updates.
Releasing the pin with iput() preserves that handling, but does not
guarantee eviction. fs_bdev_mark_dead() runs with SB_ACTIVE set, so iput()
may retain the inode in cache, whereas evict_inodes() must evict eligible
zero-reference inodes. The inode may also have been freed when iput()
returns, so the walker cannot then use it to force eviction. Using
I_FREEING preserves the existing eviction behavior without introducing
an additional last-reference transition.
The xfstests auto group passed on ext4 and XFS with known unrelated
failures excluded. No new issues were observed, and the previously
reproducible hung task no longer occurs with this patch. |
| In the Linux kernel, the following vulnerability has been resolved:
EDAC/altera: Fix use-after-free in error paths
In both altr_edac_a10_device_add() and altr_portb_setup(), the error path
freed the dci structure before releasing the devres group. Since the managed
single and double bit IRQ handlers use altdev(dci->pvt_info) as their data, an
IRQ firing between freeing dci and unregistering the IRQs could dereference
the freed memory.
Release the devres group first so the managed IRQs are unregistered
before the dci structure is freed. |
| In the Linux kernel, the following vulnerability has been resolved:
rust: irq: pass RegistrationInner as cookie to request_irq
With commit ba268514ea14 ("rust: devres: fix race condition due to
nesting"), Devres::new() returns Result<Self> by value instead of
initializing in-place via PinInit. Because request_irq() is called
inside Devres::new(), registration.inner is still uninitialized when the
IRQ is enabled, so accessing registration.inner.device() in the IRQ
callback can read uninitialized memory.
Fix this by storing the Device and handler pointer in RegistrationInner
and passing RegistrationInner as the IRQ cookie after its fields are
initialized.
This is not needed in mainline because commit 98c63ce4d760 ("rust: irq:
make Registration compatible with lifetime-bound drivers") removed
Devres from irq::Registration and moved request_irq() after all fields
are initialized. |
| In the Linux kernel, the following vulnerability has been resolved:
vsock: Fix memory leak in vmci_transport_recv_dgram_cb()
During the closure of a datagram socket, the vmci_transport_recv_dgram_cb()
function may be called, which will add the packets
to the socket's backlog; then, after the receive queue is cleared,
the __release_sock() function will move the packet back from the socket's
backlog to the receive queue, which will lead to a memory leak.
sock_close
__sock_release
__vsock_release
// take ownership by user-space
lock_sock_nested
sock_set_flag(sk, SOCK_DEAD)
vmci_transport_release
vmci_dispatch_dgs
vmci_datagram_invoke_guest_handler
vmci_transport_recv_dgram_cb
sk_receive_skb
if (!sock_owned_by_user(sk))
[...]
(!) else if sk_add_backlog()
[...]
(!) skb_queue_purge(&sk->sk_receive_queue)
release_sock
__release_sock
// move all packets from the backlog
// to the receive queue
(!) sk_backlog_rcv
vsock_queue_rcv_skb
[...]
__sock_queue_rcv_skb
if (!sock_flag(sk, SOCK_DEAD))
// Since the socket is "dead", the function will not
// be called
sk->sk_data_ready(sk)
sock_release_ownership(sk);
sock_put
Add a receive queue cleanup in the socket destructor to fix this.
syzkaller report:
unreferenced object 0xffff8880117bfb80 (size 240):
comm "irq/56-vmw_vmci", pid 205, jiffies 4295064448 (age 73.992s)
hex dump (first 32 bytes):
78 dc 26 1e 80 88 ff ff 78 dc 26 1e 80 88 ff ff x.&.....x.&.....
00 00 00 00 00 00 00 00 c0 da 26 1e 80 88 ff ff ..........&.....
backtrace:
[<ffffffff82be8d97>] __alloc_skb+0x287/0x330 net/core/skbuff.c:505
[<ffffffffa114bcbd>] vmci_transport_recv_dgram_cb+0xbd/0x210 [vmw_vsock_vmci_transport]
[<ffffffffa05072c6>] vmci_datagram_invoke_guest_handler+0x366/0x450 [vmw_vmci]
[<ffffffffa050ad75>] vmci_dispatch_dgs+0x235/0x490 [vmw_vmci]
[<ffffffffa050b025>] vmci_interrupt+0x55/0x290 [vmw_vmci]
[<ffffffff8137ad2b>] irq_thread_fn+0x8b/0x1a0 kernel/irq/manage.c:1205
[<ffffffff8137c7ae>] irq_thread+0x28e/0x530 kernel/irq/manage.c:1314
[<ffffffff81253dd6>] kthread+0x2e6/0x3a0 kernel/kthread.c:376
[<ffffffff81004392>] ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:295
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller. |
| In the Linux kernel, the following vulnerability has been resolved:
pfcp: make sure the SEID is linear before reading it
pfcp_encap_recv() only makes sure that the UDP header and the 4 byte
PFCP header are in the linear area. When the S flag is set,
pfcp_session_recv() then reads the 8 byte SEID that follows, which is
not covered by the pskb_may_pull() check.
A short PFCP packet with the S flag set, or one whose session header
lies in a fragment, therefore makes pfcp_session_recv() read beyond the
end of the packet data, and whatever it finds there is stored in the
tunnel metadata that flower later classifies on.
Pull up to the end of the SEID before reading it, and drop packets
that are too short to contain it. Reload the header pointer afterwards
since pskb_may_pull() may reallocate the skb head.
Use offsetofend() rather than sizeof(struct pfcphdr_session): the
structure is not packed, so its size is 16 bytes because of the
alignment of the __be64 member, while the header on the wire is only 12
bytes, and valid session messages would be dropped. |
| In the Linux kernel, the following vulnerability has been resolved:
devlink: fix devlink_rel reference leak when notify work is pending
devlink_rel_nested_in_notify_work_schedule() takes a reference on the
devlink_rel for the notify work and then queues the work, ignoring the
return value of schedule_delayed_work(). If the work is already pending,
nothing new is queued, the work runs only once and drops only one
reference, so the extra one is leaked together with the devlink_rel and
its index in devlink_rels.
This is easy to hit. devl_register() of a nested instance queues the
work, and if the instance is unregistered before the work has run,
devlink_rel_put() queues it again while it is still pending. The work
also keeps rescheduling itself for as long as the parent devlink lock
cannot be taken, which widens the window. Registering and unregistering
a nested devlink instance 100 times while holding the parent lock leaks
all 100 devlink_rel objects.
The reschedule path in devlink_rel_nested_in_notify_work() has the same
problem: if the work was queued again while it was running, the
reference it holds is never dropped.
Drop the reference in both places when the work was already pending.
The pending work holds its own reference, so this can not be the last
one. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: Fix unlocked list_del in drm_bridge_add()
When re-adding a bridge that was previously removed, drm_bridge_add()
drops it from bridge_lingering_list without holding bridge_lock.
Both bridge_list and bridge_lingering_list are protected by bridge_lock,
as they are concurrently modified by drm_bridge_remove() and
__drm_bridge_free(), and walked by the debugfs 'bridges' file. Running
the list_empty() test and the list_del_init() outside of the lock may
therefore corrupt either list.
Perform both under bridge_lock. |
