News & Sicurezza

CVE ID :CVE-2026-87876 Published : Sept. 9, 2026, 5:17 p.m. | 2 hours, 18 minutes ago Description :Two case-insensitive comparisons on request-derived usernames outside the main authorization path in CUPS's scheduler (printer ACL validation and private-attribute filtering) could allow bypass of username-based access controls in certain configurations. Severity: 3.0 | LOW Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-87875 Published : Sept. 9, 2026, 5:17 p.m. | 2 hours, 18 minutes ago Description :The cupsUTF32ToUTF8() function in CUPS's cups/transcode.c lacks a source-length bound and can read past the end of the source buffer, resulting in a heap out-of-bounds read. This is reachable via SNMP supply-description parsing in backend/snmp-supplies.c with attacker-controlled content. Severity: 4.3 | MEDIUM Visit the link for more details, such as CVSS details, affected products, timeline, and more...

A flaw was found in SSSD's IdP authentication provider. The eval_access_token_buf() function compares the OIDC subject identifier using strncmp() with the authenticated user's identifier length, performing a prefix comparison instead of an exact match. An attacker whose IdP identifier is a strict prefix of a target user's identifier can authenticate as the target user.

CVE ID :CVE-2026-87853 Published : Sept. 9, 2026, 5:17 p.m. | 2 hours, 18 minutes ago Description :A flaw was found in SSSD's IdP authentication provider. The eval_access_token_buf() function compares the OIDC subject identifier using strncmp() with the authenticated user's identifier length, performing a prefix comparison instead of an exact match. An attacker whose IdP identifier is a strict prefix of a target user's identifier can authenticate as the target user. Severity: 7.5 | HIGH Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-87872 Published : Sept. 9, 2026, 5:17 p.m. | 2 hours, 18 minutes ago Description :A flaw was found in the OCAPI modules (ocapi_command, ocapi_info) of the community.general Ansible collection. The shared OCAPI request helper disables TLS certificate validation on every request and the modules expose no parameter to re-enable it, while sending HTTP Basic-Auth credentials to an https endpoint. An attacker positioned on the network path between the Ansible controller and the OCAPI-managed storage/enclosure device can present any certificate, intercept the session, capture the credentials, and tamper with responses. Severity: 6.8 | MEDIUM Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-85788 Published : Sept. 9, 2026, 5:17 p.m. | 2 hours, 18 minutes ago Description :Incomplete list of disallowed inputs in the mutable SQL detector component in Amazon awslabs mysql-mcp-server might allow context-dependent actors to bypass the read-only enforcement gate and reach file-read and file-write SQL sinks via SQL inline comments that the regex engine does not treat as whitespace. To remediate this issue, users should upgrade to version 1.0.23. Severity: 5.7 | MEDIUM Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-80925 Published : Sept. 9, 2026, 5:17 p.m. | 2 hours, 18 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: vlan: fix skb_under_panic and races when toggling HW VLAN offload Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") cef51860becd ("macvlan: inherit needed_headroom and needed_tailroom from lowerdev") Severity: 0.0 | NA Visit the link for more details, such a...

CVE ID :CVE-2026-80922 Published : Sept. 9, 2026, 5:17 p.m. | 18 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Allow zero as a random number Zero is a valid random number and needs to be allowed. Otherwise the output is distinguishable from random. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-80919 Published : Sept. 9, 2026, 5:17 p.m. | 18 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format When dumping IB contents from a hung job, amdgpu_devcoredump_format() acquired the VM root PD's reservation via amdgpu_vm_lock_by_pasid() and then, for each IB, called amdgpu_bo_reserve() on the BO backing the IB. Both reservations are reservation_ww_class_mutex objects and neither used a ww_acquire_ctx, which trips lockdep: WARNING: possible recursive locking detected -------------------------------------------- kworker/u128:0 is trying to acquire lock: ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4}, at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu] but task is already holding lock: ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4}, at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu] Possible unsafe locking scenario: CPU0 ---- lock(reservation_ww_class_mutex); lock(reservation_ww_class_mutex); *** DEADLOCK *** May be due to missing lock nesting notation Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu] Call Trace: __ww_mutex_lock.constprop.0 ww_mutex_lock amdgpu_bo_reserve amdgpu_devcoredump_format+0x1594 [amdgpu] amdgpu_devcoredump_deferred_work+0xea [amdgpu] The two reservations are on different BOs in the captured trace, so the splat is a lockdep-correctness warning, not an observed deadlock. It becomes a real self-deadlock whenever the IB BO shares its dma_resv with the root PD (the always-valid case, see amdgpu_vm_is_bo_always_valid()): amdgpu_bo_reserve(abo) re-acquires the same ww_mutex without a ticket and blocks forever. With amdgpu.gpu_recovery=0 the timeout handler refires every ~2 s and each invocation produces this splat, drowning the kernel ring buffer. Now that amdgpu_vm_lock_by_pasid() takes a drm_exec context, move the IB dumping into a separate helper that locks the root PD and ...

CVE ID :CVE-2026-80920 Published : Sept. 9, 2026, 5:17 p.m. | 18 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: io_uring: defer eventfd signaling when queued from a wakeup handler io_req_local_work_add() signals the CQ ring eventfd inline when it is the one to push the first entry onto ->work_list. For DEFER_TASKRUN rings that add is frequently done from a waitqueue wakeup handler, where an arbitrary waitqueue lock is held. eventfd_signal_mask() only refuses to recurse when current->in_eventfd is set, but that bit is set by eventfd_signal_mask() itself. If the wake chain starts somewhere else, signal goes out inline and can feed back into epoll. Add IOU_F_TWQ_IN_WAKE, set it on the task_work add done from the three waitqueue callbacks, and use it to force io_eventfd_signal() down the existing call_rcu_hurry() deferral instead of signaling inline. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-80924 Published : Sept. 9, 2026, 5:17 p.m. | 2 hours, 18 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: crypto: krb5 - use kfree_sensitive() for derived key buffers crypto_krb5_prepare_encryption() and crypto_krb5_prepare_checksum() free the buffer holding the freshly derived keys with plain kfree(), leaving the key material behind in the freed slab object. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-80923 Published : Sept. 9, 2026, 5:17 p.m. | 18 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...