Export limit exceeded: 423974 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (423974 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-0435 | 2026-11-10 | N/A | ||
| Operation on a resource after expiration or release in the AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with administrative privileges to swap out a guest device without the guest's knowledge, potentially resulting in a loss of confidentiality and integrity. | ||||
| CVE-2026-123084 | 1 Redhat | 3 Ansible Automation Platform, Rhui, Satellite | 2026-11-10 | 6.5 Medium |
| An **expression language injection** has been found in the HeaderContentGuard.permit function in publication.py of the content guard in the **Pulpcore** package. The guard is supposed to check a value in a request header. It saves a jq filter and runs that filter against the header when a client asks for content. The filter is not limited to the header, and jq's env builtin also returns the environment of the content process. A low-privileged network attacker or user who can create a header content guard and attach it to a distribution can save a filter that reads that environment. The content request is allowed or denied according to the filter result. Repeating the request lets that attacker or user recover the environment, including Pulp settings held there, such as the Django secret key or the database password. | ||||
| CVE-2026-0454 | 2026-11-10 | N/A | ||
| An out-of-bounds write in the AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to corrupt global firmware variables, potentially resulting in loss of integrity. | ||||
| CVE-2026-0480 | 2026-11-10 | N/A | ||
| Missing Authentication for Critical Function in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to forge SEV-TIO guest request messages potentially compromising SEV-SNP guest memory integrity and confidentiality. | ||||
| CVE-2026-28248 | 2026-11-10 | N/A | ||
| Improper enforcement of behavioral workflow in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to potentially launch a guest whose attestation report contains an ID key digest for an ID block that doesn't match the guest's measurement resulting in loss of integrity. | ||||
| CVE-2026-28247 | 2026-11-10 | N/A | ||
| Improper Access Control Applied to Mirrored or Aliased Memory Regions in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to change the encryption bit for guest context pages potentially resulting in loss of integrity. | ||||
| CVE-2026-28249 | 2026-11-10 | N/A | ||
| Improper preservation of consistency between independent representations of shared state in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to potentially affect cache coherency for guest context pages resulting in loss of integrity. | ||||
| CVE-2026-40668 | 2026-11-10 | N/A | ||
| Authentication bypass by spoofing in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to request attestation reports for VMPL 0. | ||||
| CVE-2026-40669 | 2026-11-10 | N/A | ||
| An off-by-one error in AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with hypervisor access to corrupt the Reverse Map Table (RMP) table, potentially resulting in loss of guest memory integrity. | ||||
| CVE-2026-40670 | 2026-11-10 | N/A | ||
| Improper check for unusual or exceptional conditions in AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) could allow a privileged attacker to potentially overlap MMIO regions with DRAM regions resulting in loss of integrity. | ||||
| CVE-2026-4897 | 2 Freedesktop, Redhat | 6 Polkit, Enterprise Linux, Hummingbird and 3 more | 2026-11-10 | 5.5 Medium |
| A flaw was found in polkit. A local user can exploit this by providing a specially crafted, excessively long input to the `polkit-agent-helper-1` setuid binary via standard input (stdin). This unbounded input can lead to an out-of-memory (OOM) condition, resulting in a Denial of Service (DoS) for the system. | ||||
| CVE-2026-90834 | 2026-11-10 | 5.5 Medium | ||
| The user-mode syscall verifiers for the 16-bit ("wide data") UART API in drivers/serial/uart_handlers.c validated the wrong driver operation. z_vrfy_uart_poll_out_u16(), z_vrfy_uart_tx_u16() and z_vrfy_uart_rx_enable_u16() each ran K_SYSCALL_DRIVER_UART() against the 8-bit op (poll_out, tx, rx_enable) rather than the 16-bit op that the corresponding implementation dereferences (poll_out_u16, tx_u16, rx_enable_u16). z_impl_uart_poll_out_u16(), z_impl_uart_tx_u16() and z_impl_uart_rx_enable_u16() in include/zephyr/drivers/uart/uart_internal.h call their op unconditionally, with no NULL guard of their own, because the verifier is supposed to have established that the op exists. CONFIG_UART_WIDE_DATA is an application-selectable option that no driver selects, and only a handful of the serial drivers in the tree implement any _u16 operation; every other driver leaves those struct uart_driver_api members NULL while still providing the 8-bit ops the old check inspected. In a build with CONFIG_USERSPACE and CONFIG_UART_WIDE_DATA (plus CONFIG_UART_ASYNC_API for the uart_tx_u16() and uart_rx_enable_u16() variants), an unprivileged user-mode thread that legitimately holds access to such a UART device object can invoke the _u16 syscall: the object, permission and op checks all pass, and the kernel-side implementation then performs an indirect call through a NULL function pointer while running at supervisor privilege. The result is a CPU exception taken in kernel context instead of the intended K_OOPS or -ENOSYS return. With the default k_sys_fatal_error_handler() this halts the system (or warm-reboots it under CONFIG_RESET_ON_FATAL_ERROR), so a thread confined by the userspace sandbox can deny service to the whole device — a capability the user-mode privilege boundary is specifically meant to withhold. The call target is a fixed NULL, so there is no attacker-controlled code execution and no memory disclosure; the separate K_SYSCALL_MEMORY_ARRAY_READ()/K_SYSCALL_MEMORY_ARRAY_WRITE() bounds checks on the caller's buffer were and remain correct. The fix points each verifier at the matching _u16 op, using a plain K_SYSCALL_OBJ() object check where the op does not exist or where the implementation already tests it for NULL. | ||||
| CVE-2026-90833 | 2026-11-10 | 7.8 High | ||
| The simulated EEPROM driver validated access ranges in eeprom_range_is_valid() (drivers/eeprom/eeprom_simulator.c) with a single test, (offset + len) <= config->size. Because offset is a signed off_t and len an unsigned size_t of the same rank, the addition is evaluated in unsigned arithmetic: a negative offset combined with a compensating len wraps the sum back into the accepted range. eeprom_sim_read() and eeprom_sim_write() then memcpy() through the EEPROM(addr) macro, which is plain pointer arithmetic on the driver's static mock_eeprom array, so the copy addresses memory located before that array. eeprom_read() and eeprom_write() are __syscall entry points, and their verification handlers in drivers/eeprom/eeprom_handlers.c check only the device object and the caller's own data buffer (K_SYSCALL_MEMORY_READ/K_SYSCALL_MEMORY_WRITE) — the offset argument is passed to the driver unvalidated. With CONFIG_USERSPACE=y, a CONFIG_EEPROM_SIMULATOR device instance, and the device object granted to a user thread (the usage the in-tree tests/drivers/eeprom/api suite exercises from ZTEST_USER threads), an unprivileged thread could supply a negative offset and have the kernel perform the copy on its behalf. The result is an out-of-bounds read of kernel .bss returned into the caller's buffer and, via the write path, an out-of-bounds write of caller-supplied bytes over kernel memory preceding mock_eeprom. Both the start address and the length of the affected span are attacker-selected, so the primitive is sufficient to corrupt adjacent kernel state and escape the user-mode sandbox. Exposure is limited to builds that instantiate the simulated EEPROM (status = "okay" by default on qemu_x86 and native_sim, otherwise added by a devicetree overlay) together with userspace isolation. The fix rejects negative offsets and performs the remaining bound check without overflow. | ||||
| CVE-2026-77685 | 2026-11-10 | 8.3 High | ||
| The RFCOMM multiplexer control-channel handler in subsys/bluetooth/host/classic/rfcomm.c computed the echo length for a BT_RFCOMM_TEST command as buf->len - 1 and passed it to rfcomm_send_test(), whose length parameter is a uint8_t. A malformed but FCS-valid UIH frame on DLCI 0 can leave buf->len == 0 after rfcomm_handle_msg() pulls the two-byte MCC header, so buf->len - 1 underflows and narrows to 255. rfcomm_send_test() then copies 255 bytes out of a receive buffer that holds no remaining valid data, and appends them to an outgoing L2CAP PDU allocated with only CONFIG_BT_L2CAP_TX_MTU (253 by default for CONFIG_BT_CLASSIC) bytes of tailroom. The source read runs past the end of the ACL receive buffer into adjacent buffers of the same net_buf pool, and the destination copy overruns the transmit buffer by about eight bytes; net_buf_add_mem() performs no runtime bounds check in ordinary builds, where the underlying __ASSERT_NO_MSG() is compiled out. The trigger is a single five-byte RFCOMM frame on the multiplexer control channel, which is processed as soon as the L2CAP channel for PSM 3 is established — before any DLC exists and independent of RFCOMM session state. bt_rfcomm_init() registers that L2CAP server with .sec_level = BT_SECURITY_L1, which l2cap_br_conn_security() accepts without any link key from a peer that does not claim host Secure Simple Pairing support, so an unpaired BR/EDR device in radio range of a connectable target with CONFIG_BT_RFCOMM enabled (SPP, HFP, HSP, GOEP and similar profiles all enable it) can reach the defect. The resulting 255-byte TEST response is transmitted back to the attacker, disclosing roughly 255 bytes of adjacent stack/pool memory — including the contents of neighbouring receive buffers, which an attacker can prime with earlier packets — and the accompanying out-of-bounds write corrupts memory following the transmit buffer, which can crash the Bluetooth host. The request is trivially repeatable, so both the disclosure and the corruption can be driven at will. Two fixes are needed, and the first on its own does not close the out-of-bounds write. Fix 1 (0040ef781e1d, #115768) strips the FCS byte in rfcomm_recv() and echoes buf->len, rejecting anything over UINT8_MAX, which removes the underflow and the over-read. But rfcomm_make_uih_msg() still allocates the response with bt_l2cap_create_pdu() and never compares the requested length with the buffer's tailroom, so a well-formed TEST command carrying a pattern of about 248 bytes or more still builds a response (3-byte frame header, 2-byte message header, pattern, FCS) larger than the 253 bytes available. A pattern that long can only be received when the RFCOMM L2CAP receive MTU (CONFIG_BT_RFCOMM_L2CAP_MTU, which defaults to CONFIG_BT_BUF_ACL_RX_SIZE) exceeds CONFIG_BT_L2CAP_TX_MTU. The plain BR/EDR defaults (200 against 253) cannot reach it, but from v4.3.0 enabling CONFIG_BT_GOEP raises CONFIG_BT_BUF_ACL_RX_SIZE to 264 (265 from v4.4.0), so GOEP builds with only fix 1 applied still overrun the transmit buffer by up to eight bytes. This includes v4.3.2, the last v4.3 release, which carries fix 1 but will not receive fix 2. Fix 2 (214530895dd3, #118293) checks the tailroom on every RFCOMM PDU allocation and closes this residual write. | ||||
| CVE-2026-87042 | 2026-11-10 | 6.5 Medium | ||
| The IEEE 1588 (PTP) port implementation in subsys/net/lib/ptp/port.c adopted the logMessageInterval field of a received Delay_Resp message without any validation. port_delay_resp_msg_process() stored the raw wire value (a full-range int8_t) into port_ds.log_min_delay_req_interval, and that value is later used as a shift count by port_timer_set_timeout() when the Delay_Req timer is armed. Values below about -30 truncate the computed timeout to zero, and values with a magnitude of 64 or more perform an undefined shift of a uint64_t; the standards-defined "not applicable" encoding 0x7F fell into the latter case as well. PTP messages are received over unauthenticated link-local traffic (UDP multicast on 224.0.1.129, IPv6 multicast, or raw IEEE 802.3), and the handler accepts a Delay_Resp from any sender as long as the port is a time receiver using the end-to-end delay mechanism and the message echoes the port identity and a pending sequence id — both of which the victim itself broadcasts in its Delay_Req. Any node on the same link can therefore inject a single crafted Delay_Resp, or simply become the time transmitter and advertise the bogus interval. Once the delay timer is armed with a zero timeout, the cooperative PTP thread re-arms and retransmits a Delay_Req on every tick. Each transmission takes a buffer from the fixed CONFIG_PTP_MSG_POLL_SIZE message slab (default 10) and holds it on port->delay_req_list for three seconds, so the slab is emptied within milliseconds and ptp_msg_alloc() then blocks with K_FOREVER inside the only thread that frees those buffers — permanently stalling time synchronization until reboot. Where a transmit-timestamp callback on another thread keeps recycling buffers, the result is instead a sustained multicast Delay_Req flood and continuous CPU consumption. There is no memory corruption and no disclosure of data; the impact is availability of the PTP subsystem and of the local network segment. The fix rejects intervals outside a representable range and treats 0x7F as "not applicable" as required by IEEE 1588-2019 Table 42. The equivalent unchecked adoption of logMessageInterval from Sync messages in port_sync_msg_process(), a weaker variant of the same issue, is fixed by the companion change 334bf57f416f (#118150), which applies the same range check, ignores the field for unicast Sync messages and treats 0x7F as not applicable. | ||||
| CVE-2026-82391 | 2026-11-10 | 9.1 Critical | ||
| The HTTP/2 front-end of the Zephyr HTTP server aliased connection receive state as a scratch output. In subsys/net/lib/http/http_server_http2.c, handle_http2_static_fs_resource() passed &client->data_len as the file_size out-parameter of http_server_find_file(). client->data_len is the count of unprocessed bytes remaining in the fixed-size per-connection receive buffer client->buffer[CONFIG_HTTP_SERVER_CLIENT_BUFFER_SIZE] (256 bytes by default), an invariant every frame handler and the socket receive path rely on. Serving any static file therefore replaced that bounded value with the file's on-disk size, and nothing resets it afterwards. The defect is reached by an unauthenticated HTTP/2 GET for any file under the web root, in applications that register a static-filesystem resource (HTTP_RESOURCE_TYPE_STATIC_FS) with CONFIG_FILE_SYSTEM=y; CONFIG_HTTP_SERVER_VERSION_2 is enabled by default and no TLS or credentials are required on this path. Once client->data_len exceeds the buffer size, the frame dispatch loop in subsys/net/lib/http/http_server_core.c keeps parsing past the end of the received data, and the peer controls the bytes at client->cursor, so it can choose which fabricated frame the state machine consumes next by appending bytes after its request. The inflated length defeats the only guards on the buffer. parse_http_frame_header() and the per-frame handlers read and skip up to a 24-bit frame length beyond the buffer (out-of-bounds read); the compaction memmove(client->buffer, client->cursor, client->data_len) at the end of request handling copies the file-size number of bytes into the 256-byte buffer, overflowing the rest of struct http_client_ctx — including the current_detail/current_stream pointers, the parser_settings function-pointer table and the inactivity_timer work handler — and the adjacent client contexts in static memory; and the subsequent zsock_recv(client->fd, client->buffer + client->data_len, sizeof(client->buffer) - client->data_len, 0) underflows its size argument, writing attacker-supplied data of attacker-chosen length out of bounds. The impact is remote memory corruption in the server's single address space: at minimum a crash or hang of the device, and plausibly control-data overwrite leading to code execution. The HTTP/1 and HTTP/3 static-filesystem handlers already used a local variable and are unaffected; the fix makes the HTTP/2 handler use a local size_t file_size as well. | ||||
| CVE-2026-90832 | 2026-11-10 | 4.3 Medium | ||
| bt_hci_le_per_adv_report_common() in subsys/bluetooth/host/scan.c handles the HCI_LE_Periodic_Advertising_Report (and _v2) event. It verified that the fixed event header was present and that the controller-declared Data_Length fits the tailroom of the periodic-sync reassembly buffer, but never checked that the event actually carried as many data bytes as evt->length claims. Both reassembly paths — DATA_STATUS_PARTIAL, and DATA_STATUS_COMPLETE while a chain is already in progress — then called net_buf_simple_add_mem(&per_adv_sync->reassembly, buf->data, evt->length), copying up to 255 bytes starting past the end of the event's real payload. The Data_Length field originates in the HCI controller, so the flaw is reachable in host-only/split builds where the controller is a separate part reached over H4 UART, SPI, USB or an inter-core IPC transport: a malicious, compromised or buggy controller (or an attacker able to inject on that link) can send a report declaring a length larger than the event payload. The generic event dispatcher in subsys/bluetooth/host/hci_core.c only enforces a per-event minimum length and never cross-checks the subevent's internal length field, so nothing else catches it. Builds using Zephyr's own in-image controller are not affected, because the controller always emits a length matching the bytes it appends. Exploitation additionally requires CONFIG_BT_PER_ADV_SYNC with CONFIG_BT_PER_ADV_SYNC_BUF_SIZE > 0 (the option defaults to 0, which compiles the reassembly block out; LE Audio broadcast-sink and Public Broadcast Profile applications that reassemble fragmented periodic advertising data set it), and an established periodic advertising sync. The consequence is an out-of-bounds read of adjacent HCI RX-pool memory — including stale contents of previously received HCI events — which is copied into the reassembly buffer and then delivered to every registered bt_le_per_adv_sync_cb.recv listener as if it were received advertising data, so the disclosed memory becomes application-visible and may be forwarded off-device. The write side remains in bounds because the tailroom check uses the same length value, so there is no memory corruption; impact is limited to information disclosure and undefined behaviour on the over-read. The fix drops any report whose declared length exceeds the remaining event payload, matching the guard already present in the extended and legacy advertising report handlers. | ||||
| CVE-2026-68798 | 1 Microsoft | 7 365 Apps, Microsoft 365, Office 2021 and 4 more | 2026-11-10 | 7.8 High |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. | ||||
| CVE-2026-66805 | 2 Microsoft, Redhat | 4 Sharepoint Server, Sharepoint Server 2016, Sharepoint Server 2019 and 1 more | 2026-11-10 | 8.8 High |
| Deserialization of untrusted data in Microsoft Office SharePoint allows an authorized attacker to execute code over a network. | ||||
| CVE-2026-67177 | 2026-11-10 | 5.4 Medium | ||
| Chargemap contains a stored cross site scripting vulnerability. A remote, unauthenticated attacker could craft a payload in the username field of the account registration page and associate the new account with a victim's email. The attacker could send a forgotten password request to the victim, and the payload would execute when a victim opens the link. Fixed 2026-07-17. | ||||