OS & kernel CVEs.

Buffer Overflow in the data receiving process in NEC Corporation WebSAM WinShare Ver 7.5.0 and earlier, Ver 7.6.0 and Ver 7.7.0 through 7.7.2 on Windows allows a remote unauthenticated attacker to execute arbitrary code with SYSTEM privileges via a crafted packet with a malformed data size value in the protocol header.

Memory safety OS & kernel

Wazuh from 1.0.0 before 4.14.9 contains an out-of-bounds write vulnerability in wazuh-execd that allows privileged manager-configuration attackers to corrupt root process memory via excess ar.conf entries. Attackers controlling ossec.conf active-response blocks can push over 64 commands to agents, overflowing ReadExecConfig() arrays and crashing Active Response fleet-wide.

Memory safety OS & kernel

A use-after-free issue was addressed with improved memory management. This issue is fixed in iOS 18.7.12 and iPadOS 18.7.12, iOS 26.7.3 and iPadOS 26.7.3, iOS 27.2.1 and iPadOS 27.2.1, macOS Golden Gate 27.2.1, macOS Sequoia 15.8.3, macOS Tahoe 26.7.3, visionOS 27.2.1, watchOS 26.6.1, watchOS 27.2.1. An attacker in Bluetooth range may be able to corrupt process memory.

Memory safety OS & kernel

The NXP ENET-QOS Ethernet driver's receive work handler eth_nxp_enet_qos_rx() in drivers/ethernet/eth_nxp_enet_qos hands each processed descriptor back to the DMA by writing desc->read.control = rx_desc_refresh_flags, which sets OWN_FLAG and BUF1_ADDR_VALID_FLAG. RDES0 of a receive descriptor is the DMA buffer address in read format, but the hardware write-back aliases that word with the VLAN tag fields (or, for a context descriptor, the timestamp low word), so it is destroyed on every completion. The success path rewrites desc->read.buf1_addr before re-arming; the four drop paths — errored or non-first descriptor, net_pkt_rx_alloc() failure, invalid descriptor length, and net_pkt_get_frag() failure — did not, re-arming the ring slot with the write-back residue as its DMA target address. The drop paths are driven entirely by received traffic and need no privilege or special configuration. With the defaults for this driver (CONFIG_NET_BUF_DATA_SIZE of 128 and 16 receive descriptors) a single full-size frame consumes twelve ring slots and twelve K_NO_WAIT fragment allocations, so a short burst of frames sent to the device exhausts the receive pools and reaches the allocation-failure paths; a frame with a receive error, or any frame whose first descriptor was already dropped, reaches the non-first-descriptor path. Once a slot has been poisoned, the DMA writes the next frame received in that slot to an address derived from the frame's VLAN tag fields rather than to a receive buffer. On the supported MCX SoCs that address falls in flash or reserved space, so the transfer raises a fatal bus error that the driver only logs — there is no reset or recovery path — and reception stops permanently until the device is rebooted; where the write is silently discarded instead, the untouched buffer is later handed to the network stack with a length, delivering stale buffer contents as if they were a received frame. A single triggering event is enough to make the condition persistent, so an attacker able to send traffic to the device can permanently disable its network interface.

Memory safety OS & kernel Zephyrproject Zephyr

In the Linux kernel, the following vulnerability has been resolved: xen-netback: Fix UAF when reading statistics data The network statistic data in the driver is protected by RCU. Unfortunately when tearing down the queues after an error during connecting to the frontend (e.g. due to illegal Xenstore data filled in by the guest), the statistic data is being freed without synchronizing the RCU state. In case the data is being read via sysfs in this phase, access to already freed memory or memory being in new use is possible. Fix that by calling synchronize_net() before freeing the queue data. This is XSA-526 / CVE-2026-100080

Memory safety OS & kernel

SiYuan before 3.8.9 contains a nil pointer dereference vulnerability in privateCacheMiddleware that allows authenticated attackers to crash the kernel by reading nonexistent MCP resources. Attackers with a valid API token can send a resources/read request in an initialized MCP session, causing a panic that terminates the kernel process and interrupts service.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: xen-blkback: Avoid UAF when reading I/O statistics Reading I/O statistics via sysfs concurrently with tearing down a frontend device might result in UAF or a NULL dereference, as the reading of the statistics data is not synchronized with freeing the data. Use a rwlock for synchronizing. This is XSA-528 / CVE-2026-100082

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: fix use-after-free on lower qdisc drop The issue: teql_master_xmit() tests the slave's ndo_start_xmit() return value against NETDEV_TX_OK alone. A slave that consumes the skb but returns an error code (rc < NET_XMIT_MASK, e.g. NET_XMIT_DROP) is treated as if the skb were still owned, so the loop restores skb->dev and calls __skb_pull() on it. A VLAN slave returns the result of dev_queue_xmit() from its ndo_start_xmit() (propagated since cbbef5e18307), and when the lower qdisc drops the packet that value is NET_XMIT_DROP after the skb has been freed, giving a use-after-free in teql_master_xmit(). The Fix: test for consumption with dev_xmit_complete(), which accepts NETDEV_TX_OK and every rc < NET_XMIT_MASK, matching other callers that need to distinguish consumed results from busy. Only NETDEV_TX_OK keeps the packet counted in tx_packets/tx_bytes and advances the slave; a consumed result that is neither a success nor NET_XMIT_CN ends the attempt and is charged to tx_dropped, so lower-qdisc drops are no longer reported as good transmits. NET_XMIT_CN is counted like success because it can accompany acceptance of the current packet: pfifo_head_drop drops the old head, enqueues the current skb and returns NET_XMIT_CN. Conditions to recreate the bug: With CONFIG_NET_SCH_TEQL, CONFIG_VLAN_8021Q and CONFIG_DUMMY enabled, add lkrdummy0 (dummy) and lkrvlan0 (VLAN id 37 on lkrdummy0); set a pfifo limit 0 root on lkrdummy0 and a teql0 root on lkrvlan0; bring teql0 up with an address and send one UDP packet to it. The VLAN xmit returns NET_XMIT_DROP from the lower qdisc while holding a freed skb.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: Clear prev_fbuf on capture buffer release A KASAN slab-use-after-free read was reported in submit_audio_out_urb() when generating an impulse test signal: BUG: KASAN: slab-use-after-free in create_impulse_test_signal sound/usb/line6/playback.c:76 [inline] BUG: KASAN: slab-use-after-free in submit_audio_out_urb+0x1848/0x1b20 sound/usb/line6/playback.c:249 Read of size 2 at addr ffff888008d74870 by task syz.2.3214/7785 Allocated by task 11: kmem_cache_alloc_noprof+0x2f0/0x390 mm/slub.c:4144 line6_buffer_acquire+0x1a1/0x220 sound/usb/line6/pcm.c:158 line6_pcm_acquire+0xb6/0x230 sound/usb/line6/pcm.c:329 line6_startup_work+0x3c/0x50 sound/usb/line6/driver.c:728 Freed by task 7785: kfree+0xf8/0x390 mm/slub.c:6566 line6_buffer_release sound/usb/line6/pcm.c:176 [inline] line6_buffer_release+0xa5/0xf0 sound/usb/line6/pcm.c:170 __line6_pcm_release sound/usb/line6/pcm.c:305 [inline] line6_pcm_release+0x5a/0x80 sound/usb/line6/pcm.c:313 snd_toneport_monitor_put+0x11b/0x190 sound/usb/line6/toneport.c:183 line6pcm->prev_fbuf points into the capture PCM stream buffer (line6pcm->in.buffer), which is updated during audio_in_callback() to feed rate synchronization, software monitoring, and impulse test signal generation on playback side. When all capture streams are closed, line6_buffer_release() frees pstr->buffer with kfree(). However, it does not clear line6pcm->prev_fbuf. If playback is subsequently started (e.g. via impulse test signal volume control snd_line6_impulse_volume_put()), submit_audio_out_urb() dereferences the stale pointer line6pcm->prev_fbuf under in.lock, resulting in a slab-use-after-free read. Clear prev_fbuf and prev_fsize in line6_buffer_release() when releasing the capture stream buffer under in.lock, ensuring that no stale buffer pointer can be accessed by submit_audio_out_urb().

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: ksmbd: reserve space for the UTF-16 terminator in stream info smb_strtoUTF16() always writes a terminating zero UTF-16 unit after the converted characters, but get_file_stream_info() budgets only sizeof(struct smb2_file_stream_info) + streamlen * 2 for a stream entry and sizeof(struct smb2_file_stream_info) + 7 * 2 for the trailing "::$DATA" entry. When an entry exactly fills the 448-byte small response buffer, the terminator is written two bytes past the allocation. Reserve one extra UTF-16 unit in both budget checks. The terminator is not part of the wire format, so the reported lengths are unchanged.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix fiemap wild read on empty truncated response smb3_fiemap() treats -E2BIG from SMB2_ioctl() as a truncated range blob and loops for the next chunk. If the server reports STATUS_BUFFER_OVERFLOW with OutputCount == 0, SMB2_ioctl() returns -E2BIG with out_data == NULL and out_data_len == 0, and the existing length checks accept the empty result. The loop then evaluates next = out_data[num - 1].file_offset + ... with num == 0, reading 16 bytes before NULL. Reject a truncated range blob that contains no range, so the resume offset is never computed from an empty response. Also require the last range in a truncated blob to advance the resume offset without overflowing, and to stay within the requested range; a malicious or broken server could otherwise make no progress or underflow len and loop forever. Free the previous response buffer before retrying. Reproduced on 6.6.87.2 with a malicious SMB2 server that answers FSCTL_QUERY_ALLOCATED_RANGES with STATUS_BUFFER_OVERFLOW and OutputCount == 0; an FS_IOC_FIEMAP ioctl on the mount oopses in cifs_fiemap() with CR2 = fffffffffffffff8. The code path is unchanged on mainline.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the data area in SMB2_read() SMB2_read() copies le32_to_cpu(rsp->DataLength) bytes from (char *)rsp + rsp->DataOffset without checking that the range lies within the response actually received. A READ response with DataOffset == 0 makes smb2_get_data_area_len() zero the data length, so smb2_check_message() accepts a frame as short as the fixed response, while SMB2_read() still uses the server-supplied DataLength, capped only by CIFS_MAX_MSGSIZE and the caller's length. A malicious server can answer the synchronous read used by the mfsymlinks (or SFU) symlink parser with an 81-byte READ response carrying DataOffset 0 and DataLength 1067, making the client copy 1067 bytes from a 448-byte receive object (KASAN slab-out-of-bounds; up to 16 KiB in the general case). Clamp a zero (or header-overlapping) DataOffset to read_rsp_size, as handle_read_data() does for the asynchronous path, and reject the response unless DataOffset + DataLength fits within rsp_iov.iov_len. The SMB1 helper was fixed the same way in 5be5bdda5863.

Memory safety OS & kernel

FFmpeg through 9.0.2 contains a heap buffer overflow vulnerability in ff_dxva2_hevc_fill_picture_parameters() that allows attackers to corrupt memory via unbounded non-uniform tile counts. Attackers can supply crafted HEVC bitstreams with many non-uniformly spaced tiles to write controlled 16-bit values past fixed-size DXVA arrays during DXVA2, D3D11VA, or D3D12VA decoding on Windows.

Memory safety OS & kernel

FFmpeg through 9.0.2 contains an out-of-bounds write vulnerability in v4l2_buffer_swframe_to_buf() in libavcodec/v4l2_buffers.c because cumulative plane offsets are not checked against the V4L2 buffer length. Attackers can supply crafted video whose dimensions or padding cause unsigned wraparound in v4l2_bufref_to_buf(), making memcpy() write past the mmaped driver buffer during V4L2 M2M encoding.

Memory safety OS & kernel

The Xtensa MMU userspace port never initialized the per-thread page-table pointer thread->arch.ptables during thread setup, while arch_mem_domain_thread_add() in arch/xtensa/core/ptables.c uses a non-NULL value of that field as its "this thread is migrating from another memory domain" predicate. For a thread whose struct k_thread backing memory is not zeroed, the field holds stale data and the kernel takes the migration branch, passing that stale value to reset_region() as the base of a level-1 page table. The equivalent field on x86 is explicitly cleared in z_x86_userspace_prepare_thread() for exactly this reason; the Xtensa port adopted the predicate without the initialization. The condition is reachable from an unprivileged user-mode thread on a build with CONFIG_XTENSA_MMU, CONFIG_USERSPACE and dynamically allocated kernel objects. k_object_alloc(K_OBJ_THREAD) is a system call and allocates the thread object from the caller's resource pool without zeroing it, and the k_thread_create() verifier accepts such an object while forcing the K_USER option, so the migration branch is taken whenever the recycled heap bytes at that offset are non-zero. Because a user thread can also allocate, fill and free other kernel objects from the same heap, the stale bytes are groomable rather than merely random. Walking the bogus table in region_map_update() performs an unguarded index into l2_page_tables_counter[], may copy from and write through the attacker-influenceable level-1 base in dup_l2_table_if_needed(), and finally writes a page-table entry through a second pointer read out of that memory — once per page of the new thread's stack. The result is out-of-bounds reads and writes executed in supervisor mode, ranging from an immediate kernel panic (observed as Xtensa EXCAUSE 13 on Intel ADSP DSP firmware with user threads) to corruption of kernel memory and escape from the user-mode sandbox.

Memory safety OS & kernel Zephyrproject Zephyr

A flaw was found in BusyBox. An integer overflow occurs in the volume_id component when calculating buffer boundaries while probing filesystem metadata. An attacker can exploit this vulnerability by providing a specially crafted filesystem image on an attached storage device. When probed by utilities such as blkid, findfs, or mount, the application crashes, resulting in a Denial of Service (DoS) that prevents the system from resolving or mounting storage devices.

Memory safety OS & kernel

A flaw was found in BusyBox's udhcpc6 DHCPv6 client. A malicious server on the local network can trigger a use-after-free condition by responding with a crafted Dynamic Host Configuration Protocol for IPv6 (DHCPv6) reply packet lacking usable address options. This issue causes the client to read stale heap memory, which can result in a Denial of Service (DoS) due to an application crash or disclose previously assigned network address data in subsequent discovery requests.

Memory safety OS & kernel

A flaw was found in BusyBox. The udhcpc6 DHCPv6 client does not properly validate the size of network options sent by a server before copying them into memory. A malicious DHCPv6 server on the local network can exploit this flaw by sending a crafted reply, triggering a stack-based buffer overflow. This vulnerability could allow an attacker to achieve arbitrary code execution with root privileges or cause a denial of service (DoS) crash.

Memory safety OS & kernel

A flaw was found in BusyBox. When the TFTP (Trivial File Transfer Protocol) client requests a custom small block size and receives a standard response, it falls back to the default block size without resizing the allocated memory buffer. A malicious TFTP server can exploit this issue by sending standard-sized network packets during a transfer, causing a heap buffer overflow. This flaw allows an attacker to achieve arbitrary code execution or cause a Denial of Service (DoS) by crashing the application.

Memory safety OS & kernel

pam_usb provides hardware authentication for Linux using removable media. Prior to version 0.9.3, src/local.c (pusb_get_tty_from_display_server) allocates a 4096-byte cmdline buffer, reads up to 4096 bytes from /proc//cmdline, then replaces every NUL separator with a space. When read(2) returns exactly 4096 bytes for any process the function inspects, the buffer ends without a terminator and the subsequent strstr() calls scan past the allocation boundary. The function is invoked during normal PAM authentication when DISPLAY is set, so the read fires for every process at auth time. Consequences are bounded: strstr output is a Boolean substring match (limited info-disclosure surface) but a hostile heap layout can produce a SIGSEGV that terminates the host PAM process. This issue has been patched in version 0.9.3.

Memory safety OS & kernel

Operation on a resource after expiration or release in the Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to manipulate metadata pages potentially resulting in the loss of confidentiality and integrity of guest memory.

Memory safety OS & kernel

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.

Memory safety OS & kernel

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.

Memory safety OS & kernel

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.

Memory safety OS & kernel

Improper resource reuse in the AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with hypervisor access to write to the Reverse Map Table (RMP) protected memory, potentially resulting in loss of guest memory integrity.

Memory safety OS & kernel

Improper access control within the AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with administrative privileges to tamper with memory, potentially resulting in loss of guest memory integrity.

Memory safety OS & kernel

Improper handling of overlap between protected memory ranges in the Secure Encrypted Virtualization (SEV) firmware could allow a privileged attacker to cause misconfigurations in the RMP potentially resulting in loss of integrity.

Memory safety OS & kernel

Improper validation of unsafe equivalence in input could allow an attacker with high privileges to reclaim the ring buffer queue status page, potentially resulting in loss of guest memory integrity.

Memory safety OS & kernel

In knee_function_info of hevc_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In slice_header of hevc_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In sub_layer_hrd_parameters of hevc_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In SendInfo of UssiController.cpp, there is a possible way to corrupt memory via a dangling connection listener pointer due to a use after free. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety OS & kernel

In s_inter_rps_pred of hevc_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In cpb_cnt of avc_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In tone_mapping_info of hevc_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In fence_manager_extract_iif of fence_manager.c, there is a possible way to corrupt kernel memory via fence identifier reuse due to a use after free. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety OS & kernel

In buffering_period of avc_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In prev_run_vcore of hwcodec_firmware, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In spm_alloc of encoder, there is a possible Heap Buffer Overflow due to a heap buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In platform_rio_ncp_wdt_handler of edgetpu_rio.c, there is a possible Use After Free due to a use after free. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In CalculateSampleRate of cldma_alcedo.cc, there is a possible Heap Buffer Overflow due to a logic error in the code. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety OS & kernel

In RespondReceivedMessage of MtsMessageController.cpp, there is a possible way to trigger a double free and process abort during message retry handling due to a use after free. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety OS & kernel

In s_av1_dec_metadata_scalability of av1_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Memory safety OS & kernel

In tile_info of av1_decoder, there is a possible Heap Buffer Overflow due to a heap buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In max_num_ref_frames of avc_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In s_check_valid_tile_param_custom_tile of av1_encoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In chppWifiRangingEventNotification of clients/wifi.c, there is a possible Heap Buffer Overflow due to a logic error in the code. This could lead to remote (proximal/adjacent) escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In CMD_ENC_SET_PARAM of encoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In pic_timing of hevc_decoder, there is a possible Non-Heap Buffer Overflow due to a buffer overflow. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

Memory safety OS & kernel

In multiple locations, there is a possible out-of-bounds read due to a missing bounds check. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.

Memory safety OS & kernel