CVE Notify
19.2K subscribers
4 photos
185K links
Alert on the latest CVEs

Partner channel: @malwr
Download Telegram
🚨 CVE-2026-46005
In the Linux kernel, the following vulnerability has been resolved:

xfs: fix a resource leak in xfs_alloc_buftarg()

In the error path, call fs_put_dax() to drop the DAX
device reference.

πŸŽ–@cveNotify
🚨 CVE-2026-46006
In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: fix u32 overflow in pushbuf reloc bounds check

nouveau_gem_pushbuf_reloc_apply() validates each relocation with

if (r->reloc_bo_offset + 4 > nvbo->bo.base.size)

but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer
literal 4 promotes to unsigned int, so the addition is performed in 32
bits and wraps before the comparison against the size_t bo size.

Cast to u64 so the addition happens in 64-bit arithmetic.

[ Add Fixes: tag. - Danilo ]

πŸŽ–@cveNotify
🚨 CVE-2026-46007
In the Linux kernel, the following vulnerability has been resolved:

hwmon: (powerz) Avoid cacheline sharing for DMA buffer

Depending on the architecture the transfer buffer may share a cacheline
with the following mutex. As the buffer may be used for DMA, that is
problematic.

Use the high-level DMA helpers to make sure that cacheline sharing can
not happen.

Also drop the comment, as the helpers are documentation enough.

https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org

πŸŽ–@cveNotify
🚨 CVE-2026-46008
In the Linux kernel, the following vulnerability has been resolved:

mm/damon/core: fix damos_walk() vs kdamond_fn() exit race

When kdamond_fn() main loop is finished, the function cancels remaining
damos_walk() request and unset the damon_ctx->kdamond so that API callers
and API functions themselves can show the context is terminated.
damos_walk() adds the caller's request to the queue first. After that, it
shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond
is set). Only if the kdamond is running, damos_walk() starts waiting for
the kdamond's handling of the newly added request.

The damos_walk() requests registration and damon_ctx->kdamond unset are
protected by different mutexes, though. Hence, damos_walk() could race
with damon_ctx->kdamond unset, and result in deadlocks.

For example, let's suppose kdamond successfully finished the damow_walk()
request cancelling. Right after that, damos_walk() is called for the
context. It registers the new request, and shows the context is still
running, because damon_ctx->kdamond unset is not yet done. Hence the
damos_walk() caller starts waiting for the handling of the request.
However, the kdamond is already on the termination steps, so it never
handles the new request. As a result, the damos_walk() caller thread
infinitely waits.

Fix this by introducing another damon_ctx field, namely
walk_control_obsolete. It is protected by the
damon_ctx->walk_control_lock, which protects damos_walk() request
registration. Initialize (unset) it in kdamond_fn() before letting
damon_start() returns and set it just before the cancelling of the
remaining damos_walk() request is executed. damos_walk() reads the
obsolete field under the lock and avoids adding a new request.

After this change, only requests that are guaranteed to be handled or
cancelled are registered. Hence the after-registration DAMON context
termination check is no longer needed. Remove it together.

The issue is found by sashiko [1].

πŸŽ–@cveNotify
🚨 CVE-2026-46009
In the Linux kernel, the following vulnerability has been resolved:

PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown

epf_ntb_epc_destroy() duplicates the teardown that the caller is
supposed to do later. This leads to an oops when .allow_link fails or
when .drop_link is performed. Remove the helper.

Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC
group lifetime, and pci_epc_put() in the .drop_link path is sufficient.

πŸŽ–@cveNotify
🚨 CVE-2026-46010
In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix error handling in rxgk_extract_token()

Fix a missing bit of error handling in rxgk_extract_token(): in the event
that rxgk_decrypt_skb() returns -ENOMEM, it should just return that rather
than continuing on (for anything else, it generates an abort).

πŸŽ–@cveNotify
🚨 CVE-2026-46011
In the Linux kernel, the following vulnerability has been resolved:

media: mtk-jpeg: fix use-after-free in release path due to uncancelled work

The mtk_jpeg_release() function frees the context structure (ctx) without
first cancelling any pending or running work in ctx->jpeg_work. This
creates a race window where the workqueue callback may still be accessing
the context memory after it has been freed.

Race condition:

CPU 0 (release) CPU 1 (workqueue)
---------------- ------------------
close()
mtk_jpeg_release()
mtk_jpegenc_worker()
ctx = work->data
// accessing ctx

kfree(ctx) // freed!
access ctx // UAF!

The work is queued via queue_work() during JPEG encode/decode operations
(via mtk_jpeg_device_run). If the device is closed while work is pending
or running, the work handler will access freed memory.

Fix this by calling cancel_work_sync() BEFORE acquiring the mutex. This
ordering is critical: if cancel_work_sync() is called after mutex_lock(),
and the work handler also tries to acquire the same mutex, it would cause
a deadlock.

Note: The open error path does NOT need cancel_work_sync() because
INIT_WORK() only initializes the work structure - it does not schedule
it. Work is only scheduled later during ioctl operations.

πŸŽ–@cveNotify
🚨 CVE-2026-46012
In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix memory leaks in rxkad_verify_response()

Fix rxkad_verify_response() to free the ticket and the server key under all
circumstances by initialising the ticket pointer to NULL and then making
all paths through the function after the first allocation has been done go
through a single common epilogue that just releases everything - where all
the releases skip on a NULL pointer.

πŸŽ–@cveNotify
🚨 CVE-2026-46013
In the Linux kernel, the following vulnerability has been resolved:

mm/memfd_luo: fix physical address conversion in put_folios cleanup

In memfd_luo_retrieve_folios()'s put_folios cleanup path:

1. kho_restore_folio() expects a phys_addr_t (physical address) but
receives a raw PFN (pfolio->pfn). This causes kho_restore_page() to
check the wrong physical address (pfn << PAGE_SHIFT instead of the
actual physical address).

2. This loop lacks the !pfolio->pfn check that exists in the main
retrieval loop and memfd_luo_discard_folios(), which could
incorrectly process sparse file holes where pfn=0.

Fix by converting PFN to physical address with PFN_PHYS() and adding
the !pfolio->pfn check, matching the pattern used elsewhere in this file.

This issue was identified by the AI review.
https://sashiko.dev/#/patchset/20260323110747.193569-1-duanchenghao@kylinos.cn

πŸŽ–@cveNotify
🚨 CVE-2026-46014
In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Add missing save/restore handling of LBR MSRs

MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by
KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So
save/restore is completely broken.

Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to
LBR MSRs from userspace only (as they are read-only MSRs) if LBR
virtualization is enabled. Additionally, to correctly restore L1's LBRs
while L2 is running, make sure the LBRs are copied from the captured
VMCB01 save area in svm_copy_vmrun_state().

Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't
reported as an MSR to save/restore.

Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already
handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM:
Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the
unsupported userspace write into a nop).

[sean: guard with lbrv checks, massage changelog]

πŸŽ–@cveNotify
🚨 CVE-2026-46015
In the Linux kernel, the following vulnerability has been resolved:

tcp: call sk_data_ready() after listener migration

When inet_csk_listen_stop() migrates an established child socket from
a closing listener to another socket in the same SO_REUSEPORT group,
the target listener gets a new accept-queue entry via
inet_csk_reqsk_queue_add(), but that path never notifies the target
listener's waiters. A nonblocking accept() still works because it
checks the queue directly, but poll()/epoll_wait() waiters and
blocking accept() callers can also remain asleep indefinitely.

Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration
in inet_csk_listen_stop().

However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired
in reuseport_migrate_sock() is effectively transferred to
nreq->rsk_listener. Another CPU can then dequeue nreq via accept()
or listener shutdown, hit reqsk_put(), and drop that listener ref.
Since listeners are SOCK_RCU_FREE, wrap the post-queue_add()
dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also
covers the existing sock_net(nsk) access in that path.

The reqsk_timer_handler() path does not need the same changes for two
reasons: half-open requests become readable only after the final ACK,
where tcp_child_process() already wakes the listener; and once nreq is
visible via inet_ehash_insert(), the success path no longer touches
nsk directly.

πŸŽ–@cveNotify
🚨 CVE-2026-46016
In the Linux kernel, the following vulnerability has been resolved:

remoteproc: xlnx: Only access buffer information if IPI is buffered

In the receive callback check if message is NULL to prevent
possibility of crash by NULL pointer dereferencing.

πŸŽ–@cveNotify
🚨 CVE-2026-46017
In the Linux kernel, the following vulnerability has been resolved:

mm: fix deferred split queue races during migration

migrate_folio_move() records the deferred split queue state from src and
replays it on dst. Replaying it after remove_migration_ptes(src, dst, 0)
makes dst visible before it is requeued, so a concurrent rmap-removal path
can mark dst partially mapped and trip the WARN in deferred_split_folio().

Move the requeue before remove_migration_ptes() so dst is back on the
deferred split queue before it becomes visible again.

Because migration still holds dst locked at that point, teach
deferred_split_scan() to requeue a folio when folio_trylock() fails.
Otherwise a fully mapped underused folio can be dequeued by the shrinker
and silently lost from split_queue.

[ziy@nvidia.com: move the comment]

πŸŽ–@cveNotify
🚨 CVE-2026-46018
In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES

parse_uac2_sample_rate_range() caps the number of enumerated
rates at MAX_NR_RATES, but it only breaks out of the current
rate loop. A malformed UAC2 RANGE response with additional
triplets continues parsing the remaining triplets and repeatedly
prints "invalid uac2 rates" while probe still holds
register_mutex.

Stop the whole parse once the cap is reached and return the
number of rates collected so far.

πŸŽ–@cveNotify
🚨 CVE-2026-46019
In the Linux kernel, the following vulnerability has been resolved:

crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup

atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with
ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the
first page using free_page(), leaking the remaining 3 pages. Use
free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.

πŸŽ–@cveNotify
🚨 CVE-2026-3840
A vulnerability in Kedro version 1.2.0 allows an attacker to exploit path traversal by providing a crafted version string. The `_get_versioned_path()` method in `kedro/io/core.py` directly interpolates user-supplied version strings into filesystem paths without sanitization. This enables an attacker to escape the intended versioned dataset directory and access files outside the expected path. The issue is also reachable through the CLI via the `--load-versions` parameter, as `_split_load_versions()` in `kedro/framework/cli/utils.py` does not validate the version string. This vulnerability can lead to unauthorized file reads, data poisoning, cross-project or cross-tenant data access, and broader downstream impacts in environments where Kedro is used with automation or orchestration layers.

πŸŽ–@cveNotify
🚨 CVE-2026-12143
form-data is a library for creating readable multipart/form-data streams. In versions through 4.0.5, the `field` argument to `FormData#append` and the `filename` option are concatenated verbatim into the `Content-Disposition` header without escaping carriage return (CR), line feed (LF), or double-quote (") characters. An application that passes attacker-controlled data as a field name or filename (for example, an API gateway that turns JSON object keys into multipart field names) allows the attacker to terminate the header line and inject additional headers, or to smuggle entire additional multipart parts, into the request the application forwards to a backend. This can let the attacker add or override form fields (e.g. set `is_admin=true`) seen by the downstream parser. This is an instance of CWE-93 (CRLF injection). The fix escapes CR, LF, and `"` as `%0D`, `%0A`, and `%22` in field names and filenames, matching the serialization browsers use per the WHATWG HTML multipart/form-data encoding algorithm. Exploitation requires the consuming application to use untrusted input as a field name or filename; applications that use only fixed/trusted field names are not affected. Fixed in 2.5.6, 3.0.5, and 4.0.6.

πŸŽ–@cveNotify
🚨 CVE-2026-28742
Naxclow devices use a uniform request-signing scheme based on a hard-coded, platform-wide salt embedded in every firmware image. Once this salt is recovered from any device, an attacker can generate valid signatures for arbitrary device or account operations due to the absence of per-device keys, server-side nonce tracking, or replay protections. Combined with the system’s use of plain HTTP for control-plane traffic, the construction enables broad request forgery and impersonation across the platform.

πŸŽ–@cveNotify
🚨 CVE-2026-42932
Naxclow device identifiers use fixed manufacturing prefixes combined with sequential counters, producing a fully predictable and enumerable identifier space. Because the platform also exposes an endpoint that reveals the current identifier high-water mark, the active fleet can be enumerated.

πŸŽ–@cveNotify
🚨 CVE-2026-42947
A flaw in Naxclow's platform’s onboarding workflow allows an attacker to replay a confirm-then-bind sequence to silently reassign a device to an arbitrary account. Because the affected endpoints validate request signatures but do not confirm legitimate ownership, an attacker with any account can take over a device without user interaction while the device remains online and unaware.

πŸŽ–@cveNotify
🚨 CVE-2026-50099
During WiFi association, Naxclow device firmware prints the host network’s SSID, PSK, and negotiated WPA keys in cleartext to an exposed UART console on production hardware. The UART pads are labeled, run with default serial settings, and drop to an interactive RT-Thread shell that permits arbitrary memory reads, enabling full firmware extraction. An attacker with brief physical access, common for outdoor-mounted devices, can therefore recover WiFi credentials and bootstrap firmware-side attacks.

πŸŽ–@cveNotify