🚨 CVE-2026-10727
An OS command injection vulnerability in Ivanti EPMM before 12.9.0.1, 12.8.0.3 and 12.7.0.2 versions allows a remote authenticated attacker to execute arbitrary commands as root

🎖@cveNotify

🚨 CVE-2026-46261
In the Linux kernel, the following vulnerability has been resolved:

spi: wpcm-fiu: Fix potential NULL pointer dereference in wpcm_fiu_probe()

platform_get_resource_byname() can return NULL, which would cause a crash
when passed the pointer to resource_size().

Move the fiu->memory_size assignment after the error check for
devm_ioremap_resource() to prevent the potential NULL pointer dereference.

🎖@cveNotify

🚨 CVE-2026-46262
In the Linux kernel, the following vulnerability has been resolved:

ASoC: fsl_xcvr: Revert fix missing lock in fsl_xcvr_mode_put()

This reverts commit f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()").

The original patch attempted to acquire the card->controls_rwsem lock in
fsl_xcvr_mode_put(). However, this function is called from the upper ALSA
core function snd_ctl_elem_write(), which already holds the write lock on
controls_rwsem for the whole put operation. So there is no need to simply
hold the lock for fsl_xcvr_activate_ctl() again.

Acquiring the read lock while holding the write lock in the same thread
results in a deadlock and a hung task, as reported by Alexander Stein.

🎖@cveNotify

🚨 CVE-2026-34237
MCP Java SDK is the official Java SDK for Model Context Protocol servers and clients. Prior to versions 0.83.0, 1.0.1, and 1.1.1, there is a hardcoded wildcard CORS vulnerability. This issue has been patched in versions 0.83.0, 1.0.1, and 1.1.1.

🎖@cveNotify

🚨 CVE-2025-71313
In the Linux kernel, the following vulnerability has been resolved:

PCI: endpoint: Add missing NULL check for alloc_workqueue()

alloc_workqueue() can return NULL on memory allocation failure. Without
proper error checking, this may lead to a NULL pointer dereference when
queue_work() is later called with the NULL workqueue pointer in
epf_ntb_epc_init().

Add a NULL check immediately after alloc_workqueue() and return -ENOMEM on
failure to prevent the driver from loading with an invalid workqueue
pointer.

🎖@cveNotify

🚨 CVE-2025-71314
In the Linux kernel, the following vulnerability has been resolved:

drm/panthor: Recover from panthor_gpu_flush_caches() failures

We have seen a few cases where the whole memory subsystem is blocked
and flush operations never complete. When that happens, we want to:

- schedule a reset, so we can recover from this situation
- in the reset path, we need to reset the pending_reqs so we can send
new commands after the reset
- if more panthor_gpu_flush_caches() operations are queued after
the timeout, we skip them and return -EIO directly to avoid needless
waits (the memory block won't miraculously work again)

Note that we drop the WARN_ON()s because these hangs can be triggered
with buggy GPU jobs created by the UMD, and there's no way we can
prevent it. We do keep the error messages though.

v2:
- New patch

v3:
- Collect R-b
- Explicitly mention the fact we dropped the WARN_ON()s in the commit
message

v4:
- No changes

🎖@cveNotify

🚨 CVE-2026-46244
In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_inner: Fix IPv6 inner_thoff desync

In nft_inner_parse_l2l3(), when processing inner IPv6 packets,
ipv6_find_hdr() correctly computes the transport header offset
traversing all extension headers, but the result is immediately
overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only
accounts for the IPv6 base header. This creates a desync between
inner_thoff (wrong — points to extension header start) and l4proto
(correct — e.g., IPPROTO_TCP), enabling transport header forgery
and potential firewall bypass. This issue affects stable versions
from Linux 6.2.

For comparison, the normal (non-inner) IPv6 path correctly
preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite
ensures that ipv6_find_hdr()'s calculated transport header offset is
preserved, thereby fixing the desynchronization.

🎖@cveNotify

🚨 CVE-2026-46245
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix dc_link NULL handling in HPD init

amdgpu_dm_hpd_init() may see connectors without a valid dc_link.

The code already checks dc_link for the polling decision, but later
unconditionally dereferences it when setting up HPD interrupts.

Assign dc_link early and skip connectors where it is NULL.

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init()
error: we previously assumed 'dc_link' could be null (see line 931)

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c
923 /*
924 * Analog connectors may be hot-plugged unlike other connector
925 * types that don't support HPD. Only poll analog connectors.
926 */
927 use_polling |=
928 amdgpu_dm_connector->dc_link &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed

929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id);
930
931 dc_link = amdgpu_dm_connector->dc_link;

dc_link assigned here.

932
933 /*
934 * Get a base driver irq reference for hpd ints for the lifetime
935 * of dm. Note that only hpd interrupt types are registered with
936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on
937 * hpd_rx isn't available. DM currently controls hpd_rx
938 * explicitly with dc_interrupt_set()
939 */
--> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) {
^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here.

941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1;
942 /*
943 * TODO: There's a mismatch between mode_info.num_hpd
944 * and what bios reports as the # of connectors with hpd

🎖@cveNotify

🚨 CVE-2026-46246
In the Linux kernel, the following vulnerability has been resolved:

power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler

Using the `devm_` variant for requesting IRQ _before_ the `devm_`
variant for allocating/registering the `extcon` handle, means that the
`extcon` handle will be deallocated/unregistered _before_ the interrupt
handler (since `devm_` naturally deallocates in reverse allocation
order). This means that during removal, there is a race condition where
an interrupt can fire just _after_ the `extcon` handle has been
freed, *but* just _before_ the corresponding unregistration of the IRQ
handler has run.

This will lead to the IRQ handler calling `extcon_set_state_sync()` with
a freed `extcon` handle. Which usually crashes the system or otherwise
silently corrupts the memory...

Fix this racy use-after-free by making sure the IRQ is requested _after_
the registration of the `extcon` handle.

🎖@cveNotify

🚨 CVE-2026-46150
In the Linux kernel, the following vulnerability has been resolved:

fanotify: fix false positive on permission events

fsnotify_get_mark_safe() may return false for a mark on an unrelated group,
which results in bypassing the permission check.

Fix by skipping over detached marks that are not in the current group.

🎖@cveNotify

🚨 CVE-2026-46151
In the Linux kernel, the following vulnerability has been resolved:

usb: usblp: fix heap leak in IEEE 1284 device ID via short response

usblp_ctrl_msg() collapses the usb_control_msg() return value to
0/-errno, discarding the actual number of bytes transferred. A broken
printer can complete the GET_DEVICE_ID control transfer short and the
driver has no way to know.

usblp_cache_device_id_string() reads the 2-byte big-endian length prefix
from the response and trusts it (clamped only to the buffer bounds).
The buffer is kmalloc(1024) at probe time. A device that sends exactly
two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves
device_id_string[2..1022] holding stale kmalloc heap.

That stale data is then exposed:
- via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated
at the first NUL in the stale heap), and
- via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full
claimed length regardless of NULs, up to 1021 bytes of uninitialized
heap, with the leak size chosen by the device.

Fix this up by just zapping the buffer with zeros before each request
sent to the device.

🎖@cveNotify

🚨 CVE-2026-46152
In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: drop stray 'static' from fast-RX rx_result

ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but
its per-invocation rx_result is declared static. Concurrent callers then
share one instance and can overwrite each other's result between
ieee80211_rx_mesh_data() and the switch on res.

That can make a packet that was queued or consumed by
ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make
a packet that should continue return as queued.

Make res an automatic variable so each invocation keeps its own result.

🎖@cveNotify

🚨 CVE-2026-46153
In the Linux kernel, the following vulnerability has been resolved:

8021q: delete cleared egress QoS mappings

vlan_dev_set_egress_priority() currently keeps cleared egress
priority mappings in the hash as tombstones. Repeated set/clear cycles
with distinct skb priorities therefore accumulate mapping nodes until
device teardown and leak memory.

Delete mappings when vlan_prio is cleared instead of keeping tombstones.
Now that the egress mapping lists are RCU protected, the node can be
unlinked safely and freed after a grace period.

🎖@cveNotify

🚨 CVE-2026-46154
In the Linux kernel, the following vulnerability has been resolved:

sched_ext: Read scx_root under scx_cgroup_ops_rwsem in cgroup setters

scx_group_set_{weight,idle,bandwidth}() cache scx_root before acquiring
scx_cgroup_ops_rwsem, so the pointer can be stale by the time the op runs.
If the loaded scheduler is disabled and freed (via RCU work) and another is
enabled between the naked load and the rwsem acquire, the reader sees
scx_cgroup_enabled=true (the new scheduler's) but dereferences the freed one
- UAF on SCX_HAS_OP(sch, ...) / SCX_CALL_OP(sch, ...).

scx_cgroup_enabled is toggled only under scx_cgroup_ops_rwsem write
(scx_cgroup_{init,exit}), so reading scx_root inside the rwsem read section
correlates @sch with the enabled snapshot.

🎖@cveNotify

🚨 CVE-2026-46155
In the Linux kernel, the following vulnerability has been resolved:

smb/client: fix out-of-bounds read in smb2_compound_op()

If a server sends a truncated response but a large OutputBufferLength, and
terminates the EA list early, check_wsl_eas() returns success without
validating that the entire OutputBufferLength fits within iov_len.

Then smb2_compound_op() does:
memcpy(idata->wsl.eas, data[0], size[0]);

Where size[0] is OutputBufferLength. If iov_len is smaller than size[0],
memcpy can read beyond the end of the rsp_iov allocation and leak adjacent
kernel heap memory.

🎖@cveNotify

🚨 CVE-2026-33840
Use after free in Windows Win32K - ICOMP allows an authorized attacker to elevate privileges locally.

🎖@cveNotify

🚨 CVE-2026-42764
Issue summary: Receiving a QUIC initial packet with an invalid token may
trigger a NULL pointer dereference in the OpenSSL QUIC server with
address validation disabled.

Impact summary: NULL pointer dereference typically causes abnormal termination
of the affected QUIC server process and a Denial of Service.

If the address validation is disabled in the OpenSSL QUIC server
implementation, an attacker can crash the server by sending an initial
packet with an invalid or expired token.

By default, the client address validation is enabled in the OpenSSL QUIC server
implementation, which makes the default configuration not vulnerable
to this issue. However if the SSL_LISTENER_FLAG_NO_VALIDATE is used with
the SSL_new_listener() call, the address validation is disabled making the
vulnerable code reachable.

The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.

🎖@cveNotify

🚨 CVE-2026-42765
Issue summary: When a partial-chain certificate verification is enabled
together with OCSP response checking for the whole chain, a NULL dereference
will happen if the verified chain does not have a self-signed trusted anchor,
crashing the process.

Impact summary: A NULL pointer dereference can trigger a crash which leads to a
Denial of Service for an application.

When performing OCSP response checking for certificates in the verification
chain, the code always tries to access the next certificate as the issuer.
There is a check for a self-signed certificate. However with the partial
chain verification enabled when the chain does not have a self-signed trusted
anchor, the issuer will be NULL for the last certificate in the chain. A NULL
pointer dereference then happens.

This issue affects only applications which enable both OCSP verification
of the certificate chain (X509_V_FLAG_OCSP_RESP_CHECK_ALL) and partial
chain verification (X509_V_FLAG_PARTIAL_CHAIN) in the certificate
verification. Both flags are disabled by default. For that reason, we have
assigned Low severity to the issue.

No FIPS modules are affected by this issue as the affected code is outside
the OpenSSL FIPS module boundary.

🎖@cveNotify

🚨 CVE-2026-42766
Issue summary: A specially crafted password-encrypted CMS message
can trigger a NULL pointer dereference during CMS decryption.

Impact summary: This NULL pointer dereference leads to an application crash
and a Denial of Service.

The CMS PasswordRecipientInfo.keyDerivationAlgorithm field is defined as
OPTIONAL in the ASN.1 specification and may therefore be absent in specially
crafted inputs. During the password-based CMS decryption the OpenSSL
CMS implementation dereferences this field without first checking whether it
was present.

An attacker who supplies such a CMS message to an application performing
password-based CMS decryption can trigger an application crash, leading to
a Denial of Service.

Applications that process password-encrypted CMS messages may be affected.

The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.

🎖@cveNotify

🚨 CVE-2026-42767
Issue summary: An attacker-controlled CMP (Certificate Management Protocol)
server could trigger a NULL pointer dereference in a CMP client application.

Impact summary: A NULL pointer dereference causes a crash of the
application and a Denial of Service.

An attacker controlling a CMP server (or acting as a man-in-the-middle) could
craft a CMP response containing a CRMF (Certificate Request Message Format)
CertRepMessage with an EncryptedValue structure where the symmAlg field
has an algorithm OID but no parameters field. When the OpenSSL CMP client
processes this response, the NULL dereference occurs, causing a crash of
the CMP client.

Applications that process untrusted CMP/CRMF messages may be affected.

The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.

🎖@cveNotify

🚨 CVE-2026-42768
Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to
Bleichenbacher-style attack when an attacker is able to provide the CMS or
S/MIME messages and observe the error code and/or decryption output.

Impact summary: The Bleichenbacher-style attack allows an attacker to use the
victim's vulnerable application as a way to decrypt or sign messages with the
victim's private RSA key.

The attack is possible in 2 variants.

1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without
providing the recipient certificate. In this case OpenSSL iterates over every
KeyTransRecipientInfo (KTRI) without stopping at the first success.

An attacker who authors a message with two KTRI entries — the first one
wrapping a real CEK under the victim's public key, the second with an
arbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to
get a valid PKCS#1 v1.5 padding if the error code of the application is
available.

That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an
adaptive-chosen-ciphertext side channel from which the attacker decrypts any
RSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under
it.

2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with
the recipient certificate, and the recipient is not found, a random
key is substituted.

An attacker who authors a message and is able to compare both error code and
the result of the decryption, can mount a Bleichenbacher oracle.

We are not aware of any applications that provide a remote attacker
an opportunity to mount an attack described in these scenarios. We consider
the existence of such application very unlikely, and for this reason this
CVE has been evaluated as Low severity.

To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the
invoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described
in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit
rejection was explicitly disabled.

The implicit rejection mechanism always returns a plaintext value,
the symmetric key. This result is deterministic for the ciphertext and the
private key. The length of the decryption result can happen to match the
length of the key of the symmetric cipher that was used for the content
encryption. When a certificate is not provided, the last RecipientInfo
producing a key that looks valid will be used. It may cause getting garbage
content on decryption. As a proper way to deal with this a recipient
certificate has to be provided to identify the particular RecipientInfo for
decryption.

The FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as
CMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.

🎖@cveNotify