PULSE
FEED
ransomemperador reclama a TRANSPORTES JIMENEZ and REYES JIM REY S.A. · MX · Transportationransomdoommageddon reclama a Referans Lab Ref-Lab · TR · Technologyransomaurora reclama a Ernesto Malvestiti S.p.A. · IT · Manufacturingransomdragonforce reclama a Inside Passage Electric Cooperative, Inc · US · Energy & Utilitiesransomscarlettgroup reclama a mahsing.com.my · MY · Hospitalityransomwhitearmor reclama a LoveSac · US · Retail & E-Commerceransompayload reclama a Glückauf-Vermessung GmbH · DE · Professional Servicesransompayload reclama a Miletic GmbH · DEransompayload reclama a Edelstahl-Mechanik GmbH · DE · Manufacturingransomwhitearmor reclama a J.B Hunt · US · Transportationransompanzer reclama a Yodingenierie · BJ · Professional Servicesransomqilin reclama a White & Case · US · Professional Servicesransomqilin reclama a Hossner-Textil GmbH · DE · Manufacturingransomwhitearmor reclama a Partido Liberal · AR · Government & Defenseransomemperador reclama a TRANSPORTES JIMENEZ and REYES JIM REY S.A. · MX · Transportationransomdoommageddon reclama a Referans Lab Ref-Lab · TR · Technologyransomaurora reclama a Ernesto Malvestiti S.p.A. · IT · Manufacturingransomdragonforce reclama a Inside Passage Electric Cooperative, Inc · US · Energy & Utilitiesransomscarlettgroup reclama a mahsing.com.my · MY · Hospitalityransomwhitearmor reclama a LoveSac · US · Retail & E-Commerceransompayload reclama a Glückauf-Vermessung GmbH · DE · Professional Servicesransompayload reclama a Miletic GmbH · DEransompayload reclama a Edelstahl-Mechanik GmbH · DE · Manufacturingransomwhitearmor reclama a J.B Hunt · US · Transportationransompanzer reclama a Yodingenierie · BJ · Professional Servicesransomqilin reclama a White & Case · US · Professional Servicesransomqilin reclama a Hossner-Textil GmbH · DE · Manufacturingransomwhitearmor reclama a Partido Liberal · AR · Government & Defense
← Todos los CVEs
CVE Watch24 oct 2026

CVE-2026-64312

In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - restore callback for non-parallel fallback pcrypt ins

CVSS

7.5

Alto

EPSS

0.5%

p43

KEV

—

Exploit Today

13

0-100

Publicado: 25 jul 2026 · Última mod.: 24 oct 2026 · CWE-662

EPSS · 30d
0.5%EPSS · 30 días0.5%
2026-09-272026-10-25
Descripción técnica

In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - restore callback for non-parallel fallback pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.

Referencias oficiales
CVEs relacionados
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-720578.2 ALT
47.7%
——14In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: preserve tc_skb_cb across defragmentation tcf_ct_handle_fragments() calls nf_ct_handle_fragments() without saving and restoring skb->cb. The defrag helper clears IPCB/IP6CB, which aliases the tc_skb_cb/qdisc_skb_cb control buffer. Fragmented traffic through act_ct therefore loses qdisc metadata such as pkt_segs and can trigger WARN_ON_ONCE() in qdisc_pkt_segs() when panic_on_warn is enabled. Save and restore the full tc_skb_cb around nf_ct_handle_fragments(), matching the pattern used by ovs_ct_handle_fragments().7d
CVE-2026-684047.8 ALT
6.2%
——2In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: use wiphy work for socket owner autodisconnect nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item. That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader. Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern. Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.7d
CVE-2026-681498.4 ALT
3.0%
——1In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 ("fuse: fixes after adapting to new posix acl api") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.7d
CVE-2026-681037.1 ALT
4.2%
——1In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: reject mapping a reserved doorbell to a new queue When creating an user-queue, the user space provides a doorbell BO handle and an offset within the bo to obtain a doorbell. However current implementation using xa_store_irq() to store a doorbell, which allows a later queue created with the same BO and offset parameters to overwrite an existing queue and doorbell mapping. This can cause problems like misrouting fence IRQ processing to a wrong queue, and mislead the cleanup process of one queue erasing the mapping of another queue. This commit fixes this issue by replacing xa_store_irq with xa_insert_irq, which rejects mapping a reserved doorbell to a newly created queue (cherry picked from commit 6244eae22966350db52faf9c1369d3b2ffc5de4e)7d
CVE-2026-645567.8 ALT
5.3%
——2In the Linux kernel, the following vulnerability has been resolved: perf/core: Detach event groups during remove_on_exec perf_event_remove_on_exec() removes events by calling perf_event_exit_event(). For top-level events, this removes the event from the context with DETACH_EXIT only. This can leave inconsistent group state when a removed event is a group leader and the group contains siblings without remove_on_exec. If the group was active, the surviving siblings can remain active and attached to the removed leader's sibling list, but are no longer represented by a valid group leader on the PMU context active lists. A later close of the removed leader uses DETACH_GROUP and can promote the still-active siblings from this stale group state. The next schedule-in can then add an already-linked active_list entry again, corrupting the PMU context active list. With DEBUG_LIST enabled, this is caught as a list_add double-add in merge_sched_in(). Fix this by detaching group relationships when remove_on_exec removes an event. This preserves the existing task-exit and revoke behavior, while ensuring surviving siblings are ungrouped before the removed event leaves the context.7d
CVE-2026-640057.8 ALT
0.8%
——0In the Linux kernel, the following vulnerability has been resolved: net/smc: Do not re-initialize smc hashtables INIT_HLIST_HEAD(&smc_v*_hashinfo.ht) are called after smc_nl_init(), proto_register() and sock_register(). This can lead to smc_v*_hashinfo.ht being reset even though hash entries already exist and are being used, possibly resulting in a corrupted list. Remove unnecessary and dangerous re-initialisation of smc_v*_hashinfo.ht in smc_init(); it is implicitly initialised to zero anyhow. Add HLIST_HEAD_INIT to the definitions for clarity.7d