| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net/handshake: hand off the pinned file reference to accept_doit
handshake_req_next() removes the request from the per-net
pending list and drops hn_lock before handshake_nl_accept_doit()
reads req->hr_sk->sk_socket and dereferences sock->file (once in
FD_PREPARE() and again in get_file()). In that window a
consumer running tls_handshake_cancel() followed by sockfd_put()
(svc_sock_free) or __fput_sync() (xs_reset_transport) releases
sock->file. sock_release() then runs sock_orphan(), zeroing
sk_socket, and frees the struct socket. The accept-side code
either reads NULL through sk_socket or chases freed memory.
The submit-side sock_hold() does not prevent this. sk_refcnt
protects struct sock, but struct socket and sock->file are
independently refcounted via the file descriptor the consumer
owns. Pinning sk leaves sock and sock->file unprotected.
Retarget the accept-side dereferences at req->hr_file, which was
pinned at submit time, instead of req->hr_sk->sk_socket->file.
Pinning on its own is not sufficient: a consumer that cancels
between handshake_req_next() returning and accept_doit reaching
FD_PREPARE() takes the !remove_pending() branch in
handshake_req_cancel() and drops hr_file before the accept side
takes its own reference. Hand off an additional file reference
inside handshake_req_next(), under hn_lock, so the accept side
operates on a reference that no concurrent handshake_req_cancel()
can revoke. FD_PREPARE() consumes that handed-off reference,
either by transferring it to the new fd in fd_publish() or by
dropping it in the cleanup destructor on error; the explicit
get_file() that previously balanced FD_PREPARE() is therefore
redundant and goes away.
Update handshake_req_cancel_test2 and _test3 to simulate the
FD_PREPARE() consumption with an fput() so the kunit file-count
assertions stay balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Serialize UMP output teardown with event_input
seq_ump_process_event() borrows client->out_rfile.output without
synchronizing with the first-open and last-close transition in
seq_ump_client_open() and seq_ump_client_close().
The last output unuse can therefore drop opened[STR_OUT] to zero and
release the rawmidi file while an in-flight event_input callback is still
inside snd_rawmidi_kernel_write(). That leaves the rawmidi substream
runtime exposed to teardown before the write path has taken its own
buffer reference.
Add a per-client rwlock for the event_input-visible output file. Publish
a newly opened output file under the write side, and hold the read side
from the output lookup through snd_rawmidi_kernel_write(). The last
output close copies and clears the visible output file under the write
side, then drops the lock and releases the saved rawmidi file. Use
IRQ-safe rwlock guards because event_input can also be reached from
atomic sequencer delivery.
The buggy scenario involves two paths, with each column showing the
order within that path:
path A label: event_input path path B label: last unuse path
1. seq_ump_process_event() reads 1. seq_ump_client_close()
client->out_rfile.output. drops opened[STR_OUT] to zero.
2. snd_rawmidi_kernel_write1() 2. snd_rawmidi_kernel_release()
has not yet pinned runtime. closes the output file.
3. The writer continues using 3. close_substream() frees
the borrowed substream. substream->runtime.
This keeps the output substream and runtime alive for the full
event_input write while keeping rawmidi release outside the rwlock.
KASAN reproduced this as a slab-use-after-free in
snd_rawmidi_kernel_write1(), with allocation through
seq_ump_use()/snd_seq_port_connect() and free through
seq_ump_unuse()/snd_seq_port_disconnect().
Validation reproduced this kernel report:
KASAN slab-use-after-free in snd_rawmidi_kernel_write1+0x9d/0x400
RIP: 0033:0x7f5528af837f
Read of size 8
Call trace:
dump_stack_lvl+0x73/0xb0 (?:?)
print_report+0xd1/0x650 (?:?)
srso_alias_return_thunk+0x5/0xfbef5 (?:?)
__virt_addr_valid+0x1a7/0x340 (?:?)
kasan_complete_mode_report_info+0x64/0x200 (?:?)
kasan_report+0xf7/0x130 (?:?)
snd_rawmidi_kernel_write1+0x9d/0x400 (?:?)
__asan_load8+0x82/0xb0 (?:?)
update_stack_state+0x1ef/0x2d0 (?:?)
snd_rawmidi_kernel_write+0x1a/0x20 (?:?)
seq_ump_process_event+0xd4/0x120 (sound/core/seq/seq_ump_client.c:82)
__snd_seq_deliver_single_event+0x8a/0xe0 (?:?)
snd_seq_deliver_from_ump+0x2b2/0xd60 (?:?)
lock_acquire+0x14e/0x2e0 (?:?)
find_held_lock+0x31/0x90 (?:?)
snd_seq_port_use_ptr+0xa6/0xe0 (?:?)
__kasan_check_write+0x18/0x20 (?:?)
do_raw_read_unlock+0x32/0xa0 (?:?)
_raw_read_unlock+0x26/0x50 (?:?)
snd_seq_deliver_single_event+0x45c/0x4b0 (?:?)
snd_seq_deliver_event+0x10d/0x1b0 (?:?)
snd_seq_client_enqueue_event+0x192/0x240 (?:?)
snd_seq_write+0x2cd/0x450 (?:?)
apparmor_file_permission+0x20/0x30 (?:?)
security_file_permission+0x51/0x60 (?:?)
vfs_write+0x1ce/0x850 (?:?)
__fget_files+0x12b/0x220 (?:?)
lock_release+0xc8/0x2a0 (?:?)
__rcu_read_unlock+0x74/0x2d0 (?:?)
__fget_files+0x135/0x220 (?:?)
ksys_write+0x15a/0x180 (?:?)
rcu_is_watching+0x24/0x60 (?:?)
__x64_sys_write+0x46/0x60 (?:?)
x64_sys_call+0x7d/0x20d0 (?:?)
do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87)
entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) |
| Netty is a network application framework for development of protocol servers and clients. Prior to 4.1.136.Final and 4.2.16.Final, Netty SPDY header decoding continues inflating zlib-compressed header blocks after the raw header parser has exceeded `maxHeaderSize` and marked the frame truncated in `SpdyFrameCodec`, allowing a remote peer to send a small compressed `HEADERS` block that expands into much larger raw header data and causes compression-amplified CPU and allocation churn. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final. |
| Out-of-bounds read via sun.misc.Unsafe in Apache Fory. When out-of-band zero-copy deserialization is used, readAlignedVarUint() can read beyond the bounds of the underlying buffer. Out-of-band zero-copy deserialization is an opt-in feature; applications that do not use it are not affected.
This issue affects Apache Fory (formerly Apache Fury): from 0.5.0 before 1.4.0. Versions before 0.11.0 were published under the Maven coordinates org.apache.fury:fury-core.
Users are recommended to upgrade to version 1.4.0, which fixes the issue. |
| In the Linux kernel, the following vulnerability has been resolved:
spi: mtk-snfi: unregister ECC engine on probe failure and remove() callback
mtk_snand_probe() registers the on-host NAND ECC engine, but teardown was
missing from both probe unwind and remove-time cleanup. Add a devm cleanup
action after successful registration so
nand_ecc_unregister_on_host_hw_engine() runs automatically on probe
failures and during device removal. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Propagate error from visit_tailcall_insn
Commit e40f5a6bf88a ("bpf: correct stack liveness for tail calls") added
visit_tailcall_insn() but did not check its return value. |
| A flaw was found in the community.general Ansible collection's
jenkins_credential module. When creating a Jenkins API token
(credential_type: token), the module correctly protects the input
password with no_log=True in the argument specification, but places
the generated API token returned by the Jenkins API directly into
the Ansible task result dictionary without output suppression. The
token is emitted in plaintext via exit_json(), causing it to appear
in Ansible task output, AWX/Tower/AAP Controller job logs, callback
plugin output, CI/CD pipeline logs, and fact caching backends. An
attacker with access to any of these output channels can obtain the
Jenkins API token and gain the same privileges as the user who
created it. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: fix NULL pointer bug in svm_range_set_attr
The process_info could be NULL if user doesn't call kfd_ioctl_acquire_vm
before calling kfd_ioctl_svm.
(cherry picked from commit 83a26c812e0529eb040d31a76f73e33e637243d4) |
| In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()
A DIRECTORY entry's value field is used as the dir_offset for a
recursive call into __tb_property_parse_dir() with no depth counter.
A crafted peer that chains DIRECTORY entries into a back-reference
loop drives the parser until the kernel stack is exhausted and the
guard page fires. Any untrusted XDomain peer (cable, dock, in-line
inspector, adjacent host) that reaches the PROPERTIES_REQUEST
control-plane exchange can trigger this without authentication.
Thread a depth counter through tb_property_parse() and
__tb_property_parse_dir(), and reject blocks that exceed
TB_PROPERTY_MAX_DEPTH = 8. That is comfortably larger than any
observed legitimate XDomain layout.
Operators who do not need XDomain host-to-host discovery can disable
the path entirely with thunderbolt.xdomain=0 on the kernel command
line. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: serial: cypress_m8: validate interrupt packet headers
cypress_read_int_callback() parses the interrupt-in buffer according to
the selected Cypress packet format. Format 1 has a two-byte status/count
header and format 2 has a one-byte combined status/count header. The
usb-serial core sizes the interrupt-in buffer from the endpoint
descriptor's wMaxPacketSize, and successful interrupt transfers can
complete short when URB_SHORT_NOT_OK is not set.
Check that the completed packet contains the selected header before
reading it. Malformed short reports are ignored and the interrupt URB is
resubmitted through the existing retry path, preventing out-of-bounds
header-byte reads.
KASAN report as below:
KASAN slab-out-of-bounds in cypress_read_int_callback+0x240/0x7f0
Read of size 1
Call trace:
cypress_read_int_callback() (drivers/usb/serial/cypress_m8.c:1009)
__usb_hcd_giveback_urb()
dummy_timer()
[ johan: use constants in header length sanity checks ] |
| In the Linux kernel, the following vulnerability has been resolved:
usb: usbtmc: check URB actual_length for interrupt-IN notifications
USBTMC devices can use an optional interrupt endpoint for notification
messages. These typically contain two-byte headers indicating the
payload format, but the driver does not check if these headers are
present before accessing the data buffers. In cases where the URB
actual_length is not enough to fit these headers, the driver will either
cause an out-of-bounds read, or consume stale leftover data from a
previous notification.
Fix by checking if actual_data contains enough bytes for the headers,
otherwise resubmit URB to the interrupt endpoint. |
| ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. Prior to version 5.0.10, each table in the on-disk SQLite policy store (`/Library/Application Support/clearancekit/store.db`) is verified using an ECDSA signature stored in the `data_signatures` table. The signed payload contains only the canonical row content, with no version counter or freshness binding. An attacker who can write `store.db` and the matching `data_signatures` row — feasible during the opfilter-update window when the Endpoint Security filter is offline, or via offline-boot / decrypted-backup scenarios — can substitute a previously-captured legitimately-signed snapshot. opfilter accepts the older snapshot as fully valid on next boot because the existing signatures still verify. Version 5.0.10 patches the issue. |
| ClearanceKit intercepts file-system access events on macOS and enforces per-process access policies. The ECDSA private key used to sign the on-disk policy database (`/Library/Application Support/clearancekit/store.db`) is stored in the macOS System Keychain. The key was created via the two-step pattern `SecKeyCreateRandomKey` (in-memory) followed by `SecItemAdd(kSecValueRef:, kSecAttrAccess:)` (persist). Prior to version 5.0.10, for `kSecClassKey` items in the legacy System Keychain, `kSecAttrAccess` passed to `SecItemAdd` is silently ignored — the persisted key inherits no ACL restriction. The same access builder applied to `kSecClassGenericPassword` items correctly binds the ACL, making this bug specific to the EC key. The result is that any process running as root can use the key to produce valid signatures over arbitrary policy content. Version 5.0.10 fixes the issue. No known workarounds are available. Disabling the system extension and manually removing the System Keychain item labelled `clearancekit policy signing key` would prevent the forged-signature path but also disables policy enforcement. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops
Commit d07b26f39246 ("ksmbd: require minimum ACE size in
smb_check_perm_dacl()") introduced a transposed bounds check:
if (offsetof(struct smb_ace, sid) + aces_size < CIFS_SID_BASE_SIZE)
Since offsetof(..sid) is 8 and CIFS_SID_BASE_SIZE is 8, this evaluates
to `aces_size < 0`. Because `aces_size` is always non-negative, this
check becomes dead code and never breaks the loop.
Worse, that commit removed the old 4-byte guard, meaning the loop now
reads `ace->size` (offset 2) even when `aces_size` is 0-3 bytes. This
re-opens a 2-byte heap out-of-bounds (OOB) read past the pntsd allocation
during subsequent SMB2_CREATE operations.
Fix this by properly transposing the comparison to require at least
16 bytes (8-byte offset + 8-byte SID base), matching the correct form
used in smb_inherit_dacl(). |
| In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: Fix use after free in debug code
We're not allowed to dereference "urb" after calling
usb_hcd_giveback_urb() so save the urb->status ahead of time. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: chemical: scd30: fix division by zero in write_raw
Add a zero check for val2 before using it as a divisor when setting the
sampling frequency. A user writing a zero fractional part to the
sampling_frequency sysfs attribute triggers a division by zero in the
kernel. |
| Deserialization of untrusted data vulnerability that may allow class-registration checks to be bypassed during Java lambda deserialization. Only lambda capture class is affected
This issue affects Apache Fory: from before 1.4.0.
Users are recommended to upgrade to version 1.4.0, which fixes the issue. |
| Parse Server versions >= 9.0.0 before 9.10.0-alpha.4 and versions before 8.6.85 contain a schema disclosure vulnerability. When the GraphQL API is mounted with public introspection disabled (graphQLPublicIntrospection: false, the default), schema-derived 'Did you mean ...?' suggestions were still returned in GraphQL error messages produced during variable coercion, which were not covered by the introspection-hardening control (that only handled validation errors). An unauthenticated caller possessing only the public application id can iteratively recover hidden schema identifiers — including registered Cloud Code function names and Parse class and field names — by submitting queries or mutations whose variables contain near-miss enum values or input-object field names. This is a follow-up bypass of GHSA-8cph-rgr4-g5vj. The issue is fixed in 9.10.0-alpha.4 and 8.6.85. |
| Sparkle is a software update framework for macOS. In versions up to and including 2.9.1, `Autoupdate/AppInstaller.m`'s `shouldAcceptNewConnection:` only enforces `SUCodeSigningVerifier validateConnection:` before stage 1 completes. After `_performedStage1Installation = YES`, new connections to the registered Mach service `<bundleId>-spki` are accepted from any local process without team-ID or code-signing checks. As of time of publication, no known patched versions are available. |
| In the Linux kernel, the following vulnerability has been resolved:
auxdisplay: line-display: fix OOB read on zero-length message_store()
linedisp_display() unconditionally reads msg[count - 1] before
checking whether count is zero, so a write of zero bytes to the
message sysfs attribute hits msg[-1]:
write(fd, "", 0);
-> message_store(..., buf, count=0)
-> linedisp_display(linedisp, buf, count=0)
-> msg[count - 1] == '\n' ; OOB read
The kernfs write buffer for that store is a 1-byte allocation
(kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0),
so msg[-1] is a 1-byte read before the slab object. On a
KASAN-enabled kernel this trips an out-of-bounds report and
panics; on stock kernels it silently reads adjacent slab data
and, if that byte happens to be '\n', the following count--
wraps ssize_t 0 to -1 and is then passed to kmemdup_nul().
linedisp_display() is reached from the message_store() sysfs
callback (drivers/auxdisplay/line-display.c message attribute,
mode 0644) and from the in-tree initial-message setup with
count == -1, so the OOB path is only userspace-triggerable via
zero-byte writes; vfs_write() does not short-circuit on
count == 0 and kernfs_fop_write_iter() dispatches the store
callback regardless.
Guard the trailing-newline trim with a count check. The
existing if (!count) block then takes the clear-display path
unchanged.
Affects every auxdisplay driver that registers via
linedisp_register() / linedisp_attach(): ht16k33, max6959,
img-ascii-lcd, seg-led-gpio. |
