Mediatek
Monthly
Out-of-bounds write in MediaTek's 'vdec' hardware video-decoder path allows remote escalation of privilege on a broad set of affected MediaTek SoCs - including MT6768, MT6833, MT8186, MT8195 and MT6877 - when a victim opens or plays attacker-controlled media that reaches the vulnerable decode routine. Exploitation requires no additional execution privileges or authentication (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8) but does require user interaction, since the crafted stream must actually be rendered by the decoder; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the risk is best characterised as a credible, above-average-priority mobile vulnerability rather than an emergency. MediaTek has assigned patch ID ALPS11383899 (issue MSV-9614) and published guidance in its October 2026 product security bulletin.
Local privilege escalation in the MediaTek APU (AI Processing Unit) driver allows an attacker with existing code execution on affected devices to trigger a use-after-free, achieving full compromise of confidentiality, integrity, and availability (CVSS 8.4). The flaw affects MediaTek chipsets MT8781, MT6993, MT6899, MT8668, MT8910, and MT8793, and requires no additional privileges or user interaction once local access is obtained. No public exploit code or active exploitation is confirmed at time of analysis.
An out-of-bounds write in MediaTek modem (baseband) firmware allows an attacker operating a rogue base station to escalate privileges on a wide range of MediaTek chipsets (e.g., MT6853, MT6980, MT6991, MT8798, MT6895) once the victim's device connects to that base station; no authentication is required, but exploitation is high-complexity and requires user interaction per the assessed vector. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the risk is bounded by the need for RF proximity to a malicious base station rather than being a mass-exploitable remote flaw.
Local privilege escalation in MediaTek's APU (AI Processing Unit) allows a locally-executing attacker to corrupt memory via malformed input, potentially achieving kernel-level code execution on devices with affected chipsets (MT6899, MT8781, MT8910, MT8793, MT6993, MT8668). The vulnerability is rated CVSS 8.4 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and requires the attacker to already run code on the device, such as a malicious Android app, with no additional privileges or user interaction needed. No public exploit identified at time of analysis, and the flaw is fixed by MediaTek patch ALPS11249004.
Local privilege escalation in MediaTek NeuroPilot on affected chipsets (MT8781, MT8189, MT6993, MT8793, MT8910, MT8668, MT8188, MT6881, MT8875) allows an attacker with local code execution to trigger an out-of-bounds write in the APU/AI driver, potentially gaining high-integrity code execution with no user interaction, though no additional privileges are needed once that local app context exists. Vendor patch ALPS11249062 is available; no public exploit identified at time of analysis. It is a high-priority patch target for affected MediaTek-based devices but is not remotely reachable, limiting its scope to privilege escalation rather than initial compromise.
Local privilege escalation in MediaTek's NeuroPilot component allows an attacker with an existing foothold on a device to corrupt memory and elevate privileges via an out-of-bounds write caused by a missing bounds check (CWE-787), rated CVSS 8.4 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Affected platforms are devices built on MediaTek chipsets MT8668, MT8875, MT8781, MT8910, MT6881, MT8188, MT8189 and MT6993 that ship an unpatched NeuroPilot build. The flaw is not remotely reachable and requires local code execution (typically a running or installed Android app with no special privileges); no user interaction or elevated permissions are needed once that foothold exists, and no public exploit code was identified at time of analysis.
Local privilege escalation in MediaTek's Video HAL lets an unprivileged app already running on an affected device corrupt a fixed-size stack buffer via crafted input to the video hardware abstraction layer, yielding code execution in the HAL context with high impact to confidentiality, integrity and availability (CVSS 8.4, AV:L/PR:N/UI:N). The flaw stems from a missing bounds check (CWE-121, stack-based buffer overflow) and affects roughly four dozen MediaTek chipsets spanning the MT6xxx, MT8xxx and MT2718 families used in Android phones, tablets, Chromebooks and automotive platforms. No user interaction and no additional execution privileges are required once local code execution exists, but the attack vector is local only - remote exploitation is not indicated and no public exploit code has been identified at time of analysis. MediaTek has assigned patch ID ALPS11375674 (issue MSV-9571), delivered to OEMs through its October 2026 product security bulletin.
Memory corruption in the MediaTek cellular modem baseband (an out-of-bounds write from a missing bounds check) allows an attacker who operates a rogue base station within radio range to escalate privileges on the target device without authentication and without any user interaction. Exploitation is not reachable over the internet: the CVSS vector AV:A/AC:H/PR:N/UI:N with C:H/I:H/A:H reflects that the attacker must be in adjacent radio proximity and must successfully induce the victim's UE to attach to the malicious base station, and CISA's SSVC assessment records Exploitation: none and Automatable: no, so this is a conditionally gated baseband flaw rather than a mass-exploitation emergency. No public exploit code has been identified at time of analysis; MediaTek has released a fix under Patch ID MOLY01778988 (Issue ID MSV-8897) in its October 2026 product security bulletin.
An out-of-bounds write in MediaTek modem firmware (CWE-787) allows a nearby attacker operating a rogue base station to escalate privileges on affected devices once the user equipment attaches to the attacker-controlled cell. The flaw has a CVSS 3.1 base score of 7.5 (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) and affects dozens of MediaTek chipsets, including MT6833, MT6877, MT6983, MT6985, and MT6989, when they run unpatched modem firmware. No public exploit code has been identified at time of analysis, CISA's SSVC assessment records no observed exploitation and marks the issue as not automatable, and MediaTek has published a fix under Patch ID MOLY01778993 in its October 2026 product security bulletin.
A local out-of-bounds write in the Linux kernel's MediaTek vcodec AV1 decoder (vdec_av1_slice_setup_tile) lets an attacker who can open the mtk-vcodec V4L2 stateless AV1 decode device node and submit a crafted bitstream copy tile_info entries beyond the capacity of the mi_col_starts[]/mi_row_starts[] arrays, corrupting adjacent kernel memory. Exploitation is confined to MediaTek SoC platforms that actually ship the AV1 decoder driver and expose the decode device locally; our independent assessment rates it AV:L/AC:H/PR:L with high availability impact but only limited integrity impact and no confidentiality impact, which is substantially lower than the 7.8 base score published by NVD. No public exploit code has been identified at time of analysis, and vendor-released patches are available (Linux 6.12.111, 6.18.53, 7.2.7 and 7.3-rc3).
Uninitialized pointer dereference in the Linux kernel's MediaTek GPU power-domain driver (`pmdomain/mediatek/mfg`) can trigger a kernel fault or incorrect OPP (Operating Performance Point) configuration on first device attachment. The `prev_o` variable in `mtk_mfg_attach_dev()` is read in a conditional branch on the first loop iteration before ever being assigned, meaning it holds an indeterminate stack value; if that value is non-NULL, the kernel dereferences a stale or garbage pointer. Affected versions span stable kernel trees from commit f08e7a4e8d6a through the fixed points in 7.1.10, 7.2, and 6.19. No public exploit code and no CISA KEV listing are present; EPSS at 0.19% (9th percentile) reflects minimal real-world exploitation interest.
Use-after-free in the Linux kernel's MediaTek power domain driver exposes kernel memory to potential corruption via a dangling device-tree node pointer. In scpsys_get_bus_protection_legacy(), two error paths call of_node_put() to release infracfg and SMI device-tree node references before those nodes are passed to dev_err_probe() with the %pOF format specifier; if the put drops the last reference, the formatter dereferences freed memory. Vendor patches are available for Linux 6.18.46, 7.1.10, and 7.2, and EPSS exploitation probability sits at 0.20% (10th percentile) with no confirmed active exploitation.
Local privilege escalation and memory corruption in the Linux kernel's MediaTek power-domain (pmdomain) driver stems from a use-after-free in scpsys_get_bus_protection_legacy(), where a device node is released via of_node_put() before the error path dereferences it in dev_err_probe(). Affecting kernels using the MediaTek SCPSYS legacy bus-protection code path (typically ARM/ARM64 MediaTek SoC platforms), a local low-privileged attacker able to influence the probe error path could corrupt freed kernel memory, with high confidentiality, integrity, and availability impact. There is no public exploit identified at time of analysis, and EPSS exploitation probability is negligible (0.02%, 4th percentile).
Local privilege escalation potential in the Linux kernel's MediaTek clock gate driver stems from incorrect use of __initconst annotations on mtk_gate structures that are accessed at runtime, not just during initialization. After kernel init completes, the memory backing these structs is freed, so any runtime access reads freed memory - affecting Linux 6.18 prior to stable releases 6.18.14 and 6.19.4. CVSS rates this 7.8 (High) with local attack vector; EPSS is 0.02% and no public exploit identified at time of analysis.
Use-after-free in Linux kernel MediaTek video encoder allows local authenticated users to corrupt memory and potentially execute arbitrary code. The flaw affects the vcodec driver's encoder release path where ctx memory is freed before canceling scheduled workqueue tasks, enabling race conditions between cleanup and worker threads that may dereference freed memory. KASAN-confirmed exploitation requires local access with low privileges (CVSS AV:L/PR:L). Patches available for kernel versions 6.12.83, 6.18.24, 6.19.14, and 7.0.1. EPSS score of 0.02% (5th percentile) indicates very low probability of automated exploitation, with no public exploit identified at time of analysis.
Privilege escalation in Modem affects Nr17, Lr13, Nr16, Lr12a, and Nr15 devices through an out-of-bounds write vulnerability triggered when connecting to a rogue base station. An attacker controlling a malicious base station can achieve remote code execution and full system compromise without requiring additional privileges or user interaction beyond initial network connection. No patch is currently available for this high-severity vulnerability.
OpenWrt and its Software Development Kit contain an out-of-bounds write vulnerability in the WLAN access point firmware caused by improper bounds checking, enabling adjacent network attackers to achieve privilege escalation without user interaction or special privileges. The vulnerability carries high severity with complete impact across confidentiality, integrity, and availability, though no patch is currently available.
Nbiot Sdk contains a vulnerability that allows attackers to local escalation of privilege with User execution privileges needed (CVSS 7.8).
OpenWRT and related SDKs are vulnerable to a heap buffer overflow in the WLAN component that allows adjacent network attackers to execute privilege escalation without user interaction or special permissions. The out-of-bounds write condition enables attackers on the same network segment to gain elevated system privileges. No patch is currently available for this vulnerability.
Out-of-bounds write in Android WLAN STA driver due to missing bounds check allows local privilege escalation to System with user interaction.
Nr15 modem suffers from an uncaught exception vulnerability that allows remote attackers to trigger a denial of service by connecting a device to a malicious base station. No special privileges or user interaction are required to exploit this network-based flaw. A patch is not currently available.
In the ioctl handlers of the Mediatek Command Queue driver, there is a possible out of bounds write due to insufficient input sanitization and missing SELinux restrictions. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. No vendor patch available.
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add missing IS_ERR check for ovl_adaptor platform device platform_device_register_data() can fail and return an ERR_PTR, but the return value is used without checking, leading to an invalid pointer being stored in ddp_comp[].dev and passed to component_match_add() and mtk_ddp_comp_init(), which could result in a kernel crash. Add an IS_ERR() check to jump to the error handling path on failure.
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix ovl adaptor platform device leak mtk_drm_probe() creates an OVL adaptor platform device with platform_device_register_data() when the display pipeline requires the OVL adaptor. If a later initialization step fails, the probe error path releases the DRM resources without unregistering the already registered OVL adaptor device. The normal remove path likewise leaves the device registered after the DRM driver is unbound. Keep track of whether the OVL adaptor was successfully registered and unregister it on probe failure. Also recover the platform device from the stored DDP component device and unregister it during normal removal. The issue was identified by a static analysis tool I developed and confirmed by manual review.
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix pdev reference leak in mtk_drm_bind() When the device is not the mmsys master, mtk_drm_bind() returns early after taking a reference on the disp-mutex device via of_find_device_by_node(), without ever dropping it: mtk_drm_unbind() only puts mutex_dev for the master. Drop the reference before returning from the non-master path.
Local privilege escalation in MediaTek venc on multiple chipsets allows an attacker who already possesses System-level privileges to escalate to kernel-level code execution via a type confusion that leads to an out-of-bounds write. The vulnerability requires local access and high privileges (PR:H) with no user interaction, and no public exploit has been identified at the time of analysis. This is a post-compromise escalation step, not a remote or initial-access vector.
Local privilege escalation in MediaTek's mtee (MediaTek TEE) allows an attacker who already holds System privilege to exploit a missing bounds check, causing an out-of-bounds write that can elevate privileges on affected MediaTek chipsets. The vulnerability requires local access and high privileges (PR:H) with no user interaction, and affects 25 listed MediaTek chipset models including MT8196, MT6768, MT6769, MT6833, MT6877, MT8186, and MT8188. No public exploit code or active exploitation has been identified at time of analysis.
Local privilege escalation in MediaTek mtee allows a local attacker who already holds Android System privilege to exploit a CWE-843 type confusion and elevate code execution on affected MediaTek chipsets; user interaction is not required. The flaw is local-only (AV:L) and requires high privileges (PR:H), so it cannot be used for initial access or remote compromise and is primarily useful as a chain component after an attacker has already obtained a System-level foothold. MediaTek has published Patch ID ALPS11383899 in its October 2026 bulletin, and no public exploit identified at time of analysis.
Local privilege escalation in MediaTek's vdec (video decoder) component allows an attacker who already holds System privilege on an affected chipset to supply crafted input that triggers a type-confusion-driven out-of-bounds write, corrupting memory and achieving high confidentiality, integrity, and availability impact at a higher privilege level. The issue affects 24 MediaTek SoCs including MT8395, MT6833, MT6789, MT8195, MT6877, MT8189, MT8391, MT8676, MT8678, MT8793, MT8799, MT6855, MT8367, MT8781, MT8196, MT8910, MT8668, MT8188, MT8792, MT6769, MT6768, MT8186, MT8788E, and MT2718, across mobile, tablet, and embedded platforms. Exploitation is local only, requires the System-privilege prerequisite, and needs no user interaction; the CVSS 3.1 base score is 6.7 (MEDIUM) and no public exploit was identified at time of analysis, so the practical risk is a post-compromise escalation primitive rather than a remote entry point.
Local privilege escalation in MediaTek's meta component affects numerous MediaTek chipsets (including MT6789, MT6895, MT6985, MT8195, and others listed in EUVD-2026-92196) and allows an attacker with physical access to the device to trigger an out-of-bounds write due to a missing bounds check, achieving high confidentiality and integrity impact. No authentication, existing execution privileges, or user interaction are required once physical access is obtained. No public exploit has been identified at time of analysis; the physical access prerequisite limits remote exploitation and confines realistic abuse to scenarios such as lost or stolen devices, border inspection, or supply-chain tampering.
Local information disclosure in MediaTek Modem firmware affects devices built on more than 80 MediaTek chipset models, including MT6983, MT6895, MT6989, and MT6768, when running unpatched modem firmware. A local app with ordinary low privileges (PR:L) can access sensitive modem debug information without user interaction, yielding high confidentiality impact but no code execution or integrity/availability loss; CVSS is 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). No public exploit code has been identified at time of analysis, and there is no CISA KEV entry indicating confirmed active exploitation, but MediaTek patch MOLY01645293 and the October 2026 product security bulletin address the flaw.
Use-after-free memory corruption in MediaTek's apusys driver allows a local attacker who has already obtained Android System privilege (uid system) to escalate to kernel-level code execution on affected devices, with no user interaction required once that foothold exists. The flaw affects firmware running on a broad set of MediaTek SoCs - including MT6897, MT6899, MT6989, MT6991, MT8196, MT8678 and the other MT-series chipsets listed in MediaTek's October 2026 bulletin - and is addressed by Patch ID ALPS11076799 (Issue ID MSV-8143). Because the CVSS vector carries PR:H and AV:L, this is a second-stage privilege-escalation link that presupposes a prior System-level compromise rather than a standalone remotely reachable bug; no public exploit code or confirmed active exploitation was identified at time of analysis.
A missing permission check in MediaTek modem firmware permits an out-of-bounds read that can crash the baseband, producing a remote denial of service on affected handsets. The attack is unauthenticated (CVSS PR:N) and requires no user interaction (UI:N), but it only succeeds if the victim UE is already camped on a rogue base station the attacker controls, which is why the vector is scored AV:A/AC:H and the issue is assessed as moderate severity and low real-world priority. No public exploit code has been identified at the time of analysis, and impact is limited to availability of the modem - no confidentiality or integrity loss, and no code execution. MediaTek has issued a fix under Patch ID MOLY01774038 / Issue ID MSV-8911.
Remote denial of service against MediaTek modem (baseband) firmware affects more than 80 chipsets - including MT6765, MT6785, MT6833, MT6883, MT6985, MT6991 and MT8798 - where a missing bounds check during cellular message parsing produces an out-of-bounds read (CWE-126) that can crash the baseband. An attacker who operates a rogue base station and gets a victim UE to attach can trigger the fault with no authentication (PR:N) and no user interaction (UI:N), though the adjacent-network position and specialized radio hardware required drive the high attack complexity (AC:H) and the CVSS 3.1 score of 5.3, with impact limited to availability. Neither our independent assessment nor CISA's SSVC framework records known exploitation (Exploitation: none, Automatable: no), so no public exploit is identified at time of analysis.
Out-of-bounds read in MediaTek modem firmware (CWE-126) allows an attacker operating a rogue base station to trigger a memory over-read in the modem stack of any UE that connects to it, resulting in a remote denial of service (availability only; no data exposure or code execution). The issue affects a very wide set of MediaTek chipsets (MT6989, MT6990, MT6983, MT6768, MT6765 and dozens more) enumerated in MediaTek's October 2026 product security bulletin. No authentication or user interaction is required (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, base 5.3), but practical exploitation demands radio proximity, rogue base-station infrastructure, and the ability to coerce device attachment - CISA SSVC rates exploitation 'none' and automatable 'no', and no public exploit code or confirmed active exploitation was identified at time of analysis, making this a genuine but moderate-priority issue rather than a critical one.
Denial of service against the cellular modem firmware shipped in a very broad range of MediaTek chipsets (MT6739 through MT6993/MT8893 families) arises from an out-of-bounds read caused by a missing permission check. The precondition is that the victim user equipment has already attached to a rogue base station under the attacker's control, meaning the adversary must operate radio infrastructure within range and successfully induce attachment (downgrade or stronger-signal lure) - hence the AV:A/AC:H scoring and the LOW real-world priority despite the enormous chipset footprint. Once attached, exploiting the flaw requires no authentication (PR:N) and no user interaction (UI:N), but the outcome is availability-only (A:H, with no confidentiality or integrity impact); there is confirmed no active exploitation (CISA KEV absent), no public exploit code identified at time of analysis, and no EPSS signal was provided in the source data.
Local privilege escalation in MediaTek AIDL on affected chipsets is possible via a use-after-free memory corruption, but only after an attacker has already obtained Android System privilege and local access. Successful exploitation requires no user interaction and can yield high confidentiality, integrity, and availability impact within that privileged context. No public exploit identified at time of analysis; the vendor patch ID ALPS11185225 and the October 2026 MediaTek security bulletin address the issue.
Local privilege escalation in the aidl component shipped on a defined set of MediaTek chipsets (MT6899, MT6991, MT8910, MT8781, MT6881, MT8668, MT6989, MT8188, MT6878, MT6993, MT8695, MT8189, MT8696) allows a process that already holds Android System privilege to trigger a use-after-free, corrupt memory, and gain higher-integrity code execution with high confidentiality, integrity, and availability impact. The attack is local (AV:L) and needs no user interaction, but the PR:H prerequisite means it cannot be used for initial access and only functions as a follow-on escalation from an already-compromised privileged context. At time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; EPSS data was not supplied for this CVE. MediaTek has published a fix under Patch ID ALPS11242428 in its October 2026 Product Security Bulletin.
A missing permission check in the MediaTek AIDL (Android Interface Definition Language) component allows an attacker who already holds the Android System privilege to escalate to higher privileges locally, with no user interaction required. The expected impact is high across confidentiality, integrity, and availability (CVSS 3.1 base 6.7, AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H), but the local-only vector and the PR:H precondition mean an ordinary unprivileged app cannot trigger it directly - it is only useful as a second-stage step in an existing exploit chain or for already-privileged malware. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); this is a moderate, defense-in-depth issue rather than a top-tier emergency.
Modem denial of service in MediaTek baseband firmware allows an attacker operating a rogue base station within radio range to crash or reset a victim handset's modem through an out-of-bounds read (CWE-125) caused by an incorrect bounds check on attacker-influenced over-the-air data. The attacker must first get the target UE to camp on the malicious cell (CVSS 3.1 AV:A/AC:H), after which no privileges and no user interaction are required, and the only impact is loss of availability of the modem (A:H, C:N/I:N), yielding a 5.3 base score. There is no public exploit identified at time of analysis, CISA's SSVC assessment records Exploitation=none and Automatable=no, and applicability is limited to devices built on the enumerated MediaTek chipset models with vulnerable modem firmware, so this is a genuine but bounded, proximity-dependent availability risk rather than a mass-exploitation emergency.
Local privilege escalation in the MediaTek display component could allow an attacker who already holds Android System-level privilege to gain elevated code execution through an integer overflow (CWE-190), with no user interaction required. The flaw affects a broad set of MediaTek chipsets (including MT6893, MT6895, MT6983, MT6991, and MT8188) running unpatched firmware and is rated CVSS 6.7 (AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). No public exploit code has been identified at time of analysis, but MediaTek has published patch ID ALPS11296678 in its October 2026 security bulletin.
A double-free flaw in MediaTek's AI Processing Unit (APU) component allows a locally executing attacker - such as a malicious or compromised installed application - to crash an affected device, producing a local denial of service. Per the assessed CVSS vector (AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), no authentication, elevated privileges, or user interaction are required once local code execution is achieved, and the impact is limited to availability; there is no data exposure or code-execution gain from this defect. Exploitation is confined to devices built on the enumerated MediaTek chipsets (MT8781, MT6899, MT8668, MT8910, MT6993) running unpatched firmware; no public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
Local privilege escalation in the MediaTek display component lets a process that already holds System privilege trigger an out-of-bounds write in a display-path buffer, corrupting memory and potentially escalating to higher-level code execution with high impact to confidentiality, integrity, and availability. The defect is a missing bounds check (CWE-787) reachable without user interaction and with low attack complexity, but only from an existing System-privileged, on-device context (CVSS 3.1 6.7 Medium, AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H), so it functions as a second-stage escalation primitive rather than an initial-access or remote vector. Affected hardware spans a broad set of MediaTek chipsets including MT6991, MT6993, MT2718, MT8168-class MT8668/MT8678, MT8171, MT8188, MT8189, MT8196, MT8793, and MT8126; MediaTek has issued Patch ID ALPS11292777 (issue MSV-9195) and no public exploit code has been identified at time of analysis.
Local privilege escalation in the battery component shipped with a wide range of MediaTek chipsets (including MT6765, MT6768, MT6853, MT6893, MT6991, MT8186, MT8188 and MT8196) allows an attacker who already holds System privilege to trigger an out-of-bounds write through a missing bounds check, yielding high impact to confidentiality, integrity and availability. No user interaction is required once System access is held, and the flaw is reachable in default configurations of the listed chipsets, making it a post-compromise escalation rather than an initial foothold; the CVSS 6.7 score is dominated by the PR:H prerequisite. A vendor patch is available under MediaTek's October 2026 Product Security Bulletin (patch ID ALPS11276677, issue MSV-9217), and no public exploit code or confirmed active exploitation has been identified at time of analysis.
An out-of-bounds read/write flaw in MediaTek's ccci (cross-core/modem control) component allows an authenticated local attacker who already holds System privilege to corrupt memory, potentially leading to information disclosure, crashes, or further privilege escalation. Exploitation requires local access and, per the vendor description, user interaction - though the vendor CVSS vector omits UI:R - and is limited to specific MediaTek chipsets (MT6880, MT6890, MT6980D, MT6990, MT6986, MT6986D, MT6813, MT6988, MT2735, MT2737). No public exploit code has been identified, SSVC reports exploitation: none and not automatable, making this a high-severity but low-urgency issue due to its high-privilege prerequisite.
Denial of service in MediaTek cellular modem firmware lets an attacker running a rogue base station crash the modem of an attached device by delivering a malformed message that triggers a missing bounds check, severing cellular connectivity until the modem restarts. The flaw is availability-only (CVSS 5.3, AV:A/AC:H/PR:N/UI:N/C:N/I:N/A:H) and is gated by radio proximity plus the victim UE actually attaching to the attacker-controlled cell, so it is not reachable over the internet and carries no confidentiality or integrity impact. No public exploit code and no confirmed active exploitation were identified at time of analysis, and MediaTek has shipped fixes (patch IDs MOLY01864925 / MOLY01210562) covering more than 50 chipsets across the October 2026 product security bulletin.
Denial of service in MediaTek's cellular modem firmware can crash the baseband on a broad set of MediaTek chipsets - including MT6991, MT6988, MT6897, MT8755, MT6835, MT8792 and others - causing the device to drop connectivity or reset. Exploitation is unauthenticated (PR:N, UI:N) but requires the attacker to operate a rogue, attacker-controlled base station and to get the target user equipment to attach to it over the radio interface, which is why attack complexity is rated high (AV:A/AC:H) and impact is limited to availability (A:H; no confidentiality or integrity effect). MediaTek publishes fix identifiers MOLY01870473 / MOLY00814393 (issue MSV-9041) in its October 2026 product security bulletin; no public exploit code and no confirmed active exploitation have been identified at time of analysis, and CISA's SSVC assessment rates exploitation as 'none' with partial technical impact, keeping real-world priority moderate-to-low despite the large number of affected chipsets.
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take the pinctrl mutex. This causes a gpiochip operations to need to sleep. Worse yet, the .can_sleep field in the gpiochip is not set. This causes the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check whether it can use a spinlock or needs a mutex. In this case, it ends up taking a spinlock, then calls pinctrl_gpio_direction_output(), which takes a mutex. This causes a huge warning. While this class of Mediatek hardware does not have separate clear/set registers, the pinctrl context has a spinlock that is taken whenever a register read-modify-write is done. Also, once the GPIO function is selected / muxed in, further GPIO operations do not involve pinctrl operations or state. The GPIO direction and level values do not require toggling the pinmux or any other pin config options. Switch to directly calling mtk_pinmux_gpio_set_direction() in the GPIO set direction callbacks to avoid taking the pinctrl mutex. Drop the .gpio_set_direction field in mtk_pmxops to signal we are no longer using the pinctrl GPIO layer for setting the direction.
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences in mt8365_afe_suspend() mt8365_afe_suspend() allocates the register backup buffer with devm_kcalloc(), but does not check for allocation failure before using the returned pointer. This may lead to a NULL pointer dereference when accessing afe->reg_back_up[i]. Add the missing NULL check and return -ENOMEM on allocation failure after disabling the main clock. Also propagate the return value of mt8365_afe_suspend() in mt8365_afe_dev_runtime_suspend() so that the suspended state is not updated when suspend fails.
In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip The gpio_chip is allocated with device-managed memory but registered with the non-managed gpiochip_add_data(). This was harmless while the drivers were built-in, but once they can be built as modules and unbound/rmmod'd, devm frees the gpio_chip's memory while it is still registered, causing a use-after-free. Register it with devm_gpiochip_add_data() so it shares the same device-managed lifecycle, which also lets the manual gpiochip_remove() error paths go away.
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: free EINT resources on unbind mtk_eint_do_init() creates an IRQ domain, populates it with a mapping for every EINT line and installs a chained handler on the parent interrupt, but none of these are ever released. This was harmless while the drivers were built-in, but now that they can be built as modules and unbound/rmmod'd it leaves behind a dangling IRQ domain, interrupt mappings whose chip data points at freed memory, and a chained handler that keeps firing into that freed data. The plain allocations in mtk_eint_do_init() already use the device-managed devm_*() helpers, so tear the remaining resources down the same way: register a devm action that detaches the chained handler, waits for any in-flight handler to finish, disposes of the per-line mappings and removes the IRQ domain. This mirrors the device-managed lifecycle adopted for the GPIO chip and keeps the whole EINT setup self-cleaning on unbind.
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path When mtk_clk_register_pllfhs function fails to register a PLL, it unregisters all PLLs and cleans up itself in its error path before returning, so the function callers don't need to do it. But contrary to mtk_clk_unregister_pllfhs function, that does almost the same sequence, it does not free the IO memory mapped on fhctl node, leading to a leak. Fix this leak by factorizing the cleanup sequence in a new private function and use it both mtk_clk_register_pllfhs and mtk_clk_unregister_pllfhs functions. Also, change the loop index start value to avoid the -1 operation on index at each loop.
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Release reserved memory on cleanup The MT8192 AFE probe calls of_reserved_mem_device_init() and falls back to preallocated buffers when no reserved memory region is available. When the reserved memory assignment succeeds, however, the driver never releases it. Register a devm cleanup action after a successful reserved-memory assignment so the assignment is released on probe failure and driver unbind.
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8183: Release reserved memory on cleanup The MT8183 AFE probe can assign reserved memory with of_reserved_mem_device_init(), but the assignment is never released on driver removal or later probe failures. Register a devm cleanup action so the reserved memory assignment is released consistently, matching newer Mediatek AFE drivers.
In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check Should probe fail for HW_VOTER type power domains, this driver was unconditionally trying to perform cleanup for DIRECT_CTL domains, but only after checking if the target domain is powered on... with the DIRECT_CTL scpsys_domain_is_on() code again. And there's more: the scpsys_domain_is_on() function is also being unconditionally used in the probe path, for any power domain that has flag MTK_SCPD_KEEP_DEFAULT_OFF! This bug was never experienced by anyone because the HWV domains never failed probe, and because none of those is declared with the aforementioned flag - but it's still something critical. In order to fix this, add a check for MTCMOS Type and, based on that, call the correct functions for an "is on" check, and also do the same for the cleanup path, calling the correct functions for the "power off" action. For the latter, since there's a call to pm_genpd_remove() right before calling power_off, be cautious and add a variation of the power off functions (with a _internal suffix) for those to get a pointer to scpsys_domain instead of one to generic_pm_domain as, even if that's still working, this is way too much fragile and would break at some point.
In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series.
The Linux kernel's mediatek-gen3 PCIe host controller driver (mtk_pcie_setup_irq()) allocates IRQ domains before fetching the controller's own IRQ, so when that IRQ lookup fails the function returns early and leaves the allocated domains unreleased. Only systems built with CONFIG_PCIE_MEDIATEK_GEN3 and running on MediaTek SoC hardware contain the affected code, and the error path is not attacker-controlled under normal operation - reaching it requires local, high-privileged access capable of driving the driver's probe into the IRQ-not-found condition, with the assessed outcome being a low-severity local availability impact (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L). No public exploit has been identified at time of analysis, EPSS is 0.16% (6th percentile), and vendor fixes are published for the 6.1, 6.6, 6.12, 6.18, 7.0 and 7.1 branches.
Firmware crash in the Linux kernel's mt76/mt7921 WiFi driver allows a local low-privileged user to cause denial of service by triggering station Association ID (AID) values above the firmware's undocumented limit of 20. Affected hardware includes Mediatek mt7922 chipsets operating in AP mode (IFTYPE_AP). Exploitation requires running a non-standard hostapd configuration that allocates AIDs starting at 65 or higher - stock hostapd is not affected. No public exploit has been identified and EPSS is 0.16% (5th percentile), indicating very low exploitation likelihood.
Improper access control in the MediaTek Audio HAL on Samsung Mobile Devices running Android 14, 15, and 16 permits local unprivileged attackers to invoke restricted privileged functions within the audio subsystem. The CVSS 4.0 subsequent system impact is rated High across confidentiality, integrity, and availability (SC:H/SI:H/SA:H), indicating that successful exploitation can cascade well beyond the Audio HAL itself to compromise broader device system components. No public exploit identified at time of analysis; Samsung has released a fix in SMR Jun-2026 Release 1.
Memory exhaustion via the MediaTek SVS (Smart Voltage Scaling) debugfs interface in the Linux kernel allows a local attacker with low privileges to leak kernel memory on MediaTek SoC-based systems. The root cause is that `svs_enable_debug_write()` allocates a buffer via `memdup_user_nul()` to copy user-supplied input, but fails to free it when the subsequent `kstrtoint()` call rejects non-integer input - a classic CWE-401 missing-release flaw. No public exploit has been identified and EPSS is 0.02% (7th percentile), making this a low-urgency, patch-when-convenient issue for the narrow device population running affected MediaTek SoC kernels.
NULL pointer dereference in the Linux kernel's MediaTek DSI DRM driver causes a kernel panic during module initialization on ARM64 systems with MediaTek display hardware. The crash occurs because `mipi_dsi_host_register` triggers the `mtk_dsi_bind` callback before the `mtk_dsi` struct is stored in driver data, dereferencing a NULL pointer inside `drm_mode_object_add` and acquiring `mode_config.idr_mutex` before panicking - blocking all subsequent DRM operations on the system. No public exploit exists and EPSS stands at 0.02%, consistent with a hardware-specific local denial-of-service with no confidentiality or integrity impact.
The Nbiot SDK's wlan STA driver contains a buffer overflow vulnerability due to missing bounds checking that allows privilege escalation from System-level access. An attacker with existing System privileges can exploit this flaw without user interaction to gain elevated permissions. No patch is currently available for this vulnerability.
Improper input validation in Modem firmware (Nr16, Nr15, Nr17r, Nr17) enables remote denial of service attacks when devices connect to attacker-controlled base stations. An unauthenticated attacker can trigger a system crash without user interaction or special privileges. No patch is currently available for this vulnerability.
The Nr15 modem is susceptible to a denial-of-service attack through improper input validation when connecting to a rogue base station, allowing an attacker to trigger a system crash without requiring user interaction or special privileges. An unauthenticated attacker within radio proximity can exploit this vulnerability to render affected modems unresponsive. No patch is currently available for this issue.
Improper error handling in the modem component of Nr15, Nr16, and Nr17 devices enables denial of service attacks when a device connects to an attacker-controlled base station. An unauthenticated remote attacker can trigger a system crash without user interaction, and no patch is currently available. The vulnerability affects all Nr-series products with a CVSS score of 6.5.
An uncaught exception in WLAN AP/STA firmware for NBIoT SDK, OpenWrt, and related development kits enables adjacent network attackers to trigger a denial of service condition that renders the system unresponsive without requiring authentication or user interaction. The vulnerability affects multiple wireless products and has no available patch at this time, presenting a medium-severity risk in networked environments.
Nr15 versions up to - is affected by allocation of resources without limits or throttling (CVSS 6.5).
A missing bounds check in the Modem component affecting Nr17r, Nr16, Nr15, and Nr17 devices enables remote denial of service attacks when a user connects to an attacker-controlled base station, causing system crashes without requiring user interaction or elevated privileges. The vulnerability allows unauthenticated attackers on the same network segment to crash affected devices remotely. No patch is currently available for this vulnerability.
Denial of service attacks against Nr15, Nr16, and Nr17 modems are possible through improper input validation when a device connects to an attacker-controlled base station. An unauthenticated attacker can trigger a system crash without requiring user interaction or special privileges. No patch is currently available for this vulnerability.
Modem firmware versions Nr15, Nr16, Nr17, and Nr17r are susceptible to denial of service attacks due to insufficient bounds checking in memory operations. An attacker controlling a rogue base station can trigger a system crash on connected devices without requiring authentication or user interaction. No patch is currently available for this vulnerability.
The Nr15 Modem lacks proper input validation in message handling, allowing an attacker controlling a rogue base station to trigger a denial of service condition and crash the system without requiring user interaction or special privileges. This vulnerability affects any device connecting to the compromised base station and currently lacks a vendor patch.
In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: fix use-after-free on probe deferral The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors.
In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. [CVSS 6.5 MEDIUM]
In Modem, there is a possible system crash due to incorrect error handling. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. [CVSS 6.5 MEDIUM]
In Modem, there is a possible system crash due to incorrect error handling. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. [CVSS 6.5 MEDIUM]
Nr15 versions up to - is affected by improper check for unusual or exceptional conditions (CVSS 6.5).
In Modem, there is a possible read of uninitialized heap data due to an uncaught exception. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. [CVSS 6.5 MEDIUM]
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).
Broken AFBC (Arm Frame Buffer Compression) handling in the Linux kernel's Mediatek DRM driver on MT8188 (Genio 700) SoCs causes constant vblank timeouts and garbled display output when the 32x8/split/sparse AFBC modifier is used, which Mesa v25.0+ enables by default. A local user with GPU/display access can trigger a hung display pipeline (denial of service) and rendering of stale/garbled framebuffer contents (limited information disclosure). No public exploit identified at time of analysis, and EPSS is very low (0.17%, 7th percentile), consistent with a hardware-specific reliability bug rather than a widely weaponizable flaw.
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setup variable *nplanes is provided by user via system call argument. The possible value of q_data->fmt->num_planes is 1-3, while the value of *nplanes can be 1-8. The array access by index i can cause array out-of-bounds. Fix this bug by checking *nplanes against the array size.
In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01717526; Issue ID: MSV-5591.
In Modem, there is a possible system crash due to incorrect error handling. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01661189; Issue ID: MSV-4298.
In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01677581; Issue ID: MSV-4701.
In Modem, there is a possible out of bounds read due to a missing bounds check. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673760; Issue ID: MSV-4650.
In Modem, there is a possible system crash due to an uncaught exception. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673755; Issue ID: MSV-4647.
In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673751; Issue ID: MSV-4644.
In Modem, there is a possible system crash due to a logic error. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673749; Issue ID: MSV-4643.
Out-of-bounds write in MediaTek's 'vdec' hardware video-decoder path allows remote escalation of privilege on a broad set of affected MediaTek SoCs - including MT6768, MT6833, MT8186, MT8195 and MT6877 - when a victim opens or plays attacker-controlled media that reaches the vulnerable decode routine. Exploitation requires no additional execution privileges or authentication (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8) but does require user interaction, since the crafted stream must actually be rendered by the decoder; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the risk is best characterised as a credible, above-average-priority mobile vulnerability rather than an emergency. MediaTek has assigned patch ID ALPS11383899 (issue MSV-9614) and published guidance in its October 2026 product security bulletin.
Local privilege escalation in the MediaTek APU (AI Processing Unit) driver allows an attacker with existing code execution on affected devices to trigger a use-after-free, achieving full compromise of confidentiality, integrity, and availability (CVSS 8.4). The flaw affects MediaTek chipsets MT8781, MT6993, MT6899, MT8668, MT8910, and MT8793, and requires no additional privileges or user interaction once local access is obtained. No public exploit code or active exploitation is confirmed at time of analysis.
An out-of-bounds write in MediaTek modem (baseband) firmware allows an attacker operating a rogue base station to escalate privileges on a wide range of MediaTek chipsets (e.g., MT6853, MT6980, MT6991, MT8798, MT6895) once the victim's device connects to that base station; no authentication is required, but exploitation is high-complexity and requires user interaction per the assessed vector. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the risk is bounded by the need for RF proximity to a malicious base station rather than being a mass-exploitable remote flaw.
Local privilege escalation in MediaTek's APU (AI Processing Unit) allows a locally-executing attacker to corrupt memory via malformed input, potentially achieving kernel-level code execution on devices with affected chipsets (MT6899, MT8781, MT8910, MT8793, MT6993, MT8668). The vulnerability is rated CVSS 8.4 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and requires the attacker to already run code on the device, such as a malicious Android app, with no additional privileges or user interaction needed. No public exploit identified at time of analysis, and the flaw is fixed by MediaTek patch ALPS11249004.
Local privilege escalation in MediaTek NeuroPilot on affected chipsets (MT8781, MT8189, MT6993, MT8793, MT8910, MT8668, MT8188, MT6881, MT8875) allows an attacker with local code execution to trigger an out-of-bounds write in the APU/AI driver, potentially gaining high-integrity code execution with no user interaction, though no additional privileges are needed once that local app context exists. Vendor patch ALPS11249062 is available; no public exploit identified at time of analysis. It is a high-priority patch target for affected MediaTek-based devices but is not remotely reachable, limiting its scope to privilege escalation rather than initial compromise.
Local privilege escalation in MediaTek's NeuroPilot component allows an attacker with an existing foothold on a device to corrupt memory and elevate privileges via an out-of-bounds write caused by a missing bounds check (CWE-787), rated CVSS 8.4 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Affected platforms are devices built on MediaTek chipsets MT8668, MT8875, MT8781, MT8910, MT6881, MT8188, MT8189 and MT6993 that ship an unpatched NeuroPilot build. The flaw is not remotely reachable and requires local code execution (typically a running or installed Android app with no special privileges); no user interaction or elevated permissions are needed once that foothold exists, and no public exploit code was identified at time of analysis.
Local privilege escalation in MediaTek's Video HAL lets an unprivileged app already running on an affected device corrupt a fixed-size stack buffer via crafted input to the video hardware abstraction layer, yielding code execution in the HAL context with high impact to confidentiality, integrity and availability (CVSS 8.4, AV:L/PR:N/UI:N). The flaw stems from a missing bounds check (CWE-121, stack-based buffer overflow) and affects roughly four dozen MediaTek chipsets spanning the MT6xxx, MT8xxx and MT2718 families used in Android phones, tablets, Chromebooks and automotive platforms. No user interaction and no additional execution privileges are required once local code execution exists, but the attack vector is local only - remote exploitation is not indicated and no public exploit code has been identified at time of analysis. MediaTek has assigned patch ID ALPS11375674 (issue MSV-9571), delivered to OEMs through its October 2026 product security bulletin.
Memory corruption in the MediaTek cellular modem baseband (an out-of-bounds write from a missing bounds check) allows an attacker who operates a rogue base station within radio range to escalate privileges on the target device without authentication and without any user interaction. Exploitation is not reachable over the internet: the CVSS vector AV:A/AC:H/PR:N/UI:N with C:H/I:H/A:H reflects that the attacker must be in adjacent radio proximity and must successfully induce the victim's UE to attach to the malicious base station, and CISA's SSVC assessment records Exploitation: none and Automatable: no, so this is a conditionally gated baseband flaw rather than a mass-exploitation emergency. No public exploit code has been identified at time of analysis; MediaTek has released a fix under Patch ID MOLY01778988 (Issue ID MSV-8897) in its October 2026 product security bulletin.
An out-of-bounds write in MediaTek modem firmware (CWE-787) allows a nearby attacker operating a rogue base station to escalate privileges on affected devices once the user equipment attaches to the attacker-controlled cell. The flaw has a CVSS 3.1 base score of 7.5 (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) and affects dozens of MediaTek chipsets, including MT6833, MT6877, MT6983, MT6985, and MT6989, when they run unpatched modem firmware. No public exploit code has been identified at time of analysis, CISA's SSVC assessment records no observed exploitation and marks the issue as not automatable, and MediaTek has published a fix under Patch ID MOLY01778993 in its October 2026 product security bulletin.
A local out-of-bounds write in the Linux kernel's MediaTek vcodec AV1 decoder (vdec_av1_slice_setup_tile) lets an attacker who can open the mtk-vcodec V4L2 stateless AV1 decode device node and submit a crafted bitstream copy tile_info entries beyond the capacity of the mi_col_starts[]/mi_row_starts[] arrays, corrupting adjacent kernel memory. Exploitation is confined to MediaTek SoC platforms that actually ship the AV1 decoder driver and expose the decode device locally; our independent assessment rates it AV:L/AC:H/PR:L with high availability impact but only limited integrity impact and no confidentiality impact, which is substantially lower than the 7.8 base score published by NVD. No public exploit code has been identified at time of analysis, and vendor-released patches are available (Linux 6.12.111, 6.18.53, 7.2.7 and 7.3-rc3).
Uninitialized pointer dereference in the Linux kernel's MediaTek GPU power-domain driver (`pmdomain/mediatek/mfg`) can trigger a kernel fault or incorrect OPP (Operating Performance Point) configuration on first device attachment. The `prev_o` variable in `mtk_mfg_attach_dev()` is read in a conditional branch on the first loop iteration before ever being assigned, meaning it holds an indeterminate stack value; if that value is non-NULL, the kernel dereferences a stale or garbage pointer. Affected versions span stable kernel trees from commit f08e7a4e8d6a through the fixed points in 7.1.10, 7.2, and 6.19. No public exploit code and no CISA KEV listing are present; EPSS at 0.19% (9th percentile) reflects minimal real-world exploitation interest.
Use-after-free in the Linux kernel's MediaTek power domain driver exposes kernel memory to potential corruption via a dangling device-tree node pointer. In scpsys_get_bus_protection_legacy(), two error paths call of_node_put() to release infracfg and SMI device-tree node references before those nodes are passed to dev_err_probe() with the %pOF format specifier; if the put drops the last reference, the formatter dereferences freed memory. Vendor patches are available for Linux 6.18.46, 7.1.10, and 7.2, and EPSS exploitation probability sits at 0.20% (10th percentile) with no confirmed active exploitation.
Local privilege escalation and memory corruption in the Linux kernel's MediaTek power-domain (pmdomain) driver stems from a use-after-free in scpsys_get_bus_protection_legacy(), where a device node is released via of_node_put() before the error path dereferences it in dev_err_probe(). Affecting kernels using the MediaTek SCPSYS legacy bus-protection code path (typically ARM/ARM64 MediaTek SoC platforms), a local low-privileged attacker able to influence the probe error path could corrupt freed kernel memory, with high confidentiality, integrity, and availability impact. There is no public exploit identified at time of analysis, and EPSS exploitation probability is negligible (0.02%, 4th percentile).
Local privilege escalation potential in the Linux kernel's MediaTek clock gate driver stems from incorrect use of __initconst annotations on mtk_gate structures that are accessed at runtime, not just during initialization. After kernel init completes, the memory backing these structs is freed, so any runtime access reads freed memory - affecting Linux 6.18 prior to stable releases 6.18.14 and 6.19.4. CVSS rates this 7.8 (High) with local attack vector; EPSS is 0.02% and no public exploit identified at time of analysis.
Use-after-free in Linux kernel MediaTek video encoder allows local authenticated users to corrupt memory and potentially execute arbitrary code. The flaw affects the vcodec driver's encoder release path where ctx memory is freed before canceling scheduled workqueue tasks, enabling race conditions between cleanup and worker threads that may dereference freed memory. KASAN-confirmed exploitation requires local access with low privileges (CVSS AV:L/PR:L). Patches available for kernel versions 6.12.83, 6.18.24, 6.19.14, and 7.0.1. EPSS score of 0.02% (5th percentile) indicates very low probability of automated exploitation, with no public exploit identified at time of analysis.
Privilege escalation in Modem affects Nr17, Lr13, Nr16, Lr12a, and Nr15 devices through an out-of-bounds write vulnerability triggered when connecting to a rogue base station. An attacker controlling a malicious base station can achieve remote code execution and full system compromise without requiring additional privileges or user interaction beyond initial network connection. No patch is currently available for this high-severity vulnerability.
OpenWrt and its Software Development Kit contain an out-of-bounds write vulnerability in the WLAN access point firmware caused by improper bounds checking, enabling adjacent network attackers to achieve privilege escalation without user interaction or special privileges. The vulnerability carries high severity with complete impact across confidentiality, integrity, and availability, though no patch is currently available.
Nbiot Sdk contains a vulnerability that allows attackers to local escalation of privilege with User execution privileges needed (CVSS 7.8).
OpenWRT and related SDKs are vulnerable to a heap buffer overflow in the WLAN component that allows adjacent network attackers to execute privilege escalation without user interaction or special permissions. The out-of-bounds write condition enables attackers on the same network segment to gain elevated system privileges. No patch is currently available for this vulnerability.
Out-of-bounds write in Android WLAN STA driver due to missing bounds check allows local privilege escalation to System with user interaction.
Nr15 modem suffers from an uncaught exception vulnerability that allows remote attackers to trigger a denial of service by connecting a device to a malicious base station. No special privileges or user interaction are required to exploit this network-based flaw. A patch is not currently available.
In the ioctl handlers of the Mediatek Command Queue driver, there is a possible out of bounds write due to insufficient input sanitization and missing SELinux restrictions. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. No vendor patch available.
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add missing IS_ERR check for ovl_adaptor platform device platform_device_register_data() can fail and return an ERR_PTR, but the return value is used without checking, leading to an invalid pointer being stored in ddp_comp[].dev and passed to component_match_add() and mtk_ddp_comp_init(), which could result in a kernel crash. Add an IS_ERR() check to jump to the error handling path on failure.
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix ovl adaptor platform device leak mtk_drm_probe() creates an OVL adaptor platform device with platform_device_register_data() when the display pipeline requires the OVL adaptor. If a later initialization step fails, the probe error path releases the DRM resources without unregistering the already registered OVL adaptor device. The normal remove path likewise leaves the device registered after the DRM driver is unbound. Keep track of whether the OVL adaptor was successfully registered and unregister it on probe failure. Also recover the platform device from the stored DDP component device and unregister it during normal removal. The issue was identified by a static analysis tool I developed and confirmed by manual review.
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix pdev reference leak in mtk_drm_bind() When the device is not the mmsys master, mtk_drm_bind() returns early after taking a reference on the disp-mutex device via of_find_device_by_node(), without ever dropping it: mtk_drm_unbind() only puts mutex_dev for the master. Drop the reference before returning from the non-master path.
Local privilege escalation in MediaTek venc on multiple chipsets allows an attacker who already possesses System-level privileges to escalate to kernel-level code execution via a type confusion that leads to an out-of-bounds write. The vulnerability requires local access and high privileges (PR:H) with no user interaction, and no public exploit has been identified at the time of analysis. This is a post-compromise escalation step, not a remote or initial-access vector.
Local privilege escalation in MediaTek's mtee (MediaTek TEE) allows an attacker who already holds System privilege to exploit a missing bounds check, causing an out-of-bounds write that can elevate privileges on affected MediaTek chipsets. The vulnerability requires local access and high privileges (PR:H) with no user interaction, and affects 25 listed MediaTek chipset models including MT8196, MT6768, MT6769, MT6833, MT6877, MT8186, and MT8188. No public exploit code or active exploitation has been identified at time of analysis.
Local privilege escalation in MediaTek mtee allows a local attacker who already holds Android System privilege to exploit a CWE-843 type confusion and elevate code execution on affected MediaTek chipsets; user interaction is not required. The flaw is local-only (AV:L) and requires high privileges (PR:H), so it cannot be used for initial access or remote compromise and is primarily useful as a chain component after an attacker has already obtained a System-level foothold. MediaTek has published Patch ID ALPS11383899 in its October 2026 bulletin, and no public exploit identified at time of analysis.
Local privilege escalation in MediaTek's vdec (video decoder) component allows an attacker who already holds System privilege on an affected chipset to supply crafted input that triggers a type-confusion-driven out-of-bounds write, corrupting memory and achieving high confidentiality, integrity, and availability impact at a higher privilege level. The issue affects 24 MediaTek SoCs including MT8395, MT6833, MT6789, MT8195, MT6877, MT8189, MT8391, MT8676, MT8678, MT8793, MT8799, MT6855, MT8367, MT8781, MT8196, MT8910, MT8668, MT8188, MT8792, MT6769, MT6768, MT8186, MT8788E, and MT2718, across mobile, tablet, and embedded platforms. Exploitation is local only, requires the System-privilege prerequisite, and needs no user interaction; the CVSS 3.1 base score is 6.7 (MEDIUM) and no public exploit was identified at time of analysis, so the practical risk is a post-compromise escalation primitive rather than a remote entry point.
Local privilege escalation in MediaTek's meta component affects numerous MediaTek chipsets (including MT6789, MT6895, MT6985, MT8195, and others listed in EUVD-2026-92196) and allows an attacker with physical access to the device to trigger an out-of-bounds write due to a missing bounds check, achieving high confidentiality and integrity impact. No authentication, existing execution privileges, or user interaction are required once physical access is obtained. No public exploit has been identified at time of analysis; the physical access prerequisite limits remote exploitation and confines realistic abuse to scenarios such as lost or stolen devices, border inspection, or supply-chain tampering.
Local information disclosure in MediaTek Modem firmware affects devices built on more than 80 MediaTek chipset models, including MT6983, MT6895, MT6989, and MT6768, when running unpatched modem firmware. A local app with ordinary low privileges (PR:L) can access sensitive modem debug information without user interaction, yielding high confidentiality impact but no code execution or integrity/availability loss; CVSS is 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). No public exploit code has been identified at time of analysis, and there is no CISA KEV entry indicating confirmed active exploitation, but MediaTek patch MOLY01645293 and the October 2026 product security bulletin address the flaw.
Use-after-free memory corruption in MediaTek's apusys driver allows a local attacker who has already obtained Android System privilege (uid system) to escalate to kernel-level code execution on affected devices, with no user interaction required once that foothold exists. The flaw affects firmware running on a broad set of MediaTek SoCs - including MT6897, MT6899, MT6989, MT6991, MT8196, MT8678 and the other MT-series chipsets listed in MediaTek's October 2026 bulletin - and is addressed by Patch ID ALPS11076799 (Issue ID MSV-8143). Because the CVSS vector carries PR:H and AV:L, this is a second-stage privilege-escalation link that presupposes a prior System-level compromise rather than a standalone remotely reachable bug; no public exploit code or confirmed active exploitation was identified at time of analysis.
A missing permission check in MediaTek modem firmware permits an out-of-bounds read that can crash the baseband, producing a remote denial of service on affected handsets. The attack is unauthenticated (CVSS PR:N) and requires no user interaction (UI:N), but it only succeeds if the victim UE is already camped on a rogue base station the attacker controls, which is why the vector is scored AV:A/AC:H and the issue is assessed as moderate severity and low real-world priority. No public exploit code has been identified at the time of analysis, and impact is limited to availability of the modem - no confidentiality or integrity loss, and no code execution. MediaTek has issued a fix under Patch ID MOLY01774038 / Issue ID MSV-8911.
Remote denial of service against MediaTek modem (baseband) firmware affects more than 80 chipsets - including MT6765, MT6785, MT6833, MT6883, MT6985, MT6991 and MT8798 - where a missing bounds check during cellular message parsing produces an out-of-bounds read (CWE-126) that can crash the baseband. An attacker who operates a rogue base station and gets a victim UE to attach can trigger the fault with no authentication (PR:N) and no user interaction (UI:N), though the adjacent-network position and specialized radio hardware required drive the high attack complexity (AC:H) and the CVSS 3.1 score of 5.3, with impact limited to availability. Neither our independent assessment nor CISA's SSVC framework records known exploitation (Exploitation: none, Automatable: no), so no public exploit is identified at time of analysis.
Out-of-bounds read in MediaTek modem firmware (CWE-126) allows an attacker operating a rogue base station to trigger a memory over-read in the modem stack of any UE that connects to it, resulting in a remote denial of service (availability only; no data exposure or code execution). The issue affects a very wide set of MediaTek chipsets (MT6989, MT6990, MT6983, MT6768, MT6765 and dozens more) enumerated in MediaTek's October 2026 product security bulletin. No authentication or user interaction is required (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, base 5.3), but practical exploitation demands radio proximity, rogue base-station infrastructure, and the ability to coerce device attachment - CISA SSVC rates exploitation 'none' and automatable 'no', and no public exploit code or confirmed active exploitation was identified at time of analysis, making this a genuine but moderate-priority issue rather than a critical one.
Denial of service against the cellular modem firmware shipped in a very broad range of MediaTek chipsets (MT6739 through MT6993/MT8893 families) arises from an out-of-bounds read caused by a missing permission check. The precondition is that the victim user equipment has already attached to a rogue base station under the attacker's control, meaning the adversary must operate radio infrastructure within range and successfully induce attachment (downgrade or stronger-signal lure) - hence the AV:A/AC:H scoring and the LOW real-world priority despite the enormous chipset footprint. Once attached, exploiting the flaw requires no authentication (PR:N) and no user interaction (UI:N), but the outcome is availability-only (A:H, with no confidentiality or integrity impact); there is confirmed no active exploitation (CISA KEV absent), no public exploit code identified at time of analysis, and no EPSS signal was provided in the source data.
Local privilege escalation in MediaTek AIDL on affected chipsets is possible via a use-after-free memory corruption, but only after an attacker has already obtained Android System privilege and local access. Successful exploitation requires no user interaction and can yield high confidentiality, integrity, and availability impact within that privileged context. No public exploit identified at time of analysis; the vendor patch ID ALPS11185225 and the October 2026 MediaTek security bulletin address the issue.
Local privilege escalation in the aidl component shipped on a defined set of MediaTek chipsets (MT6899, MT6991, MT8910, MT8781, MT6881, MT8668, MT6989, MT8188, MT6878, MT6993, MT8695, MT8189, MT8696) allows a process that already holds Android System privilege to trigger a use-after-free, corrupt memory, and gain higher-integrity code execution with high confidentiality, integrity, and availability impact. The attack is local (AV:L) and needs no user interaction, but the PR:H prerequisite means it cannot be used for initial access and only functions as a follow-on escalation from an already-compromised privileged context. At time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; EPSS data was not supplied for this CVE. MediaTek has published a fix under Patch ID ALPS11242428 in its October 2026 Product Security Bulletin.
A missing permission check in the MediaTek AIDL (Android Interface Definition Language) component allows an attacker who already holds the Android System privilege to escalate to higher privileges locally, with no user interaction required. The expected impact is high across confidentiality, integrity, and availability (CVSS 3.1 base 6.7, AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H), but the local-only vector and the PR:H precondition mean an ordinary unprivileged app cannot trigger it directly - it is only useful as a second-stage step in an existing exploit chain or for already-privileged malware. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV); this is a moderate, defense-in-depth issue rather than a top-tier emergency.
Modem denial of service in MediaTek baseband firmware allows an attacker operating a rogue base station within radio range to crash or reset a victim handset's modem through an out-of-bounds read (CWE-125) caused by an incorrect bounds check on attacker-influenced over-the-air data. The attacker must first get the target UE to camp on the malicious cell (CVSS 3.1 AV:A/AC:H), after which no privileges and no user interaction are required, and the only impact is loss of availability of the modem (A:H, C:N/I:N), yielding a 5.3 base score. There is no public exploit identified at time of analysis, CISA's SSVC assessment records Exploitation=none and Automatable=no, and applicability is limited to devices built on the enumerated MediaTek chipset models with vulnerable modem firmware, so this is a genuine but bounded, proximity-dependent availability risk rather than a mass-exploitation emergency.
Local privilege escalation in the MediaTek display component could allow an attacker who already holds Android System-level privilege to gain elevated code execution through an integer overflow (CWE-190), with no user interaction required. The flaw affects a broad set of MediaTek chipsets (including MT6893, MT6895, MT6983, MT6991, and MT8188) running unpatched firmware and is rated CVSS 6.7 (AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). No public exploit code has been identified at time of analysis, but MediaTek has published patch ID ALPS11296678 in its October 2026 security bulletin.
A double-free flaw in MediaTek's AI Processing Unit (APU) component allows a locally executing attacker - such as a malicious or compromised installed application - to crash an affected device, producing a local denial of service. Per the assessed CVSS vector (AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), no authentication, elevated privileges, or user interaction are required once local code execution is achieved, and the impact is limited to availability; there is no data exposure or code-execution gain from this defect. Exploitation is confined to devices built on the enumerated MediaTek chipsets (MT8781, MT6899, MT8668, MT8910, MT6993) running unpatched firmware; no public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
Local privilege escalation in the MediaTek display component lets a process that already holds System privilege trigger an out-of-bounds write in a display-path buffer, corrupting memory and potentially escalating to higher-level code execution with high impact to confidentiality, integrity, and availability. The defect is a missing bounds check (CWE-787) reachable without user interaction and with low attack complexity, but only from an existing System-privileged, on-device context (CVSS 3.1 6.7 Medium, AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H), so it functions as a second-stage escalation primitive rather than an initial-access or remote vector. Affected hardware spans a broad set of MediaTek chipsets including MT6991, MT6993, MT2718, MT8168-class MT8668/MT8678, MT8171, MT8188, MT8189, MT8196, MT8793, and MT8126; MediaTek has issued Patch ID ALPS11292777 (issue MSV-9195) and no public exploit code has been identified at time of analysis.
Local privilege escalation in the battery component shipped with a wide range of MediaTek chipsets (including MT6765, MT6768, MT6853, MT6893, MT6991, MT8186, MT8188 and MT8196) allows an attacker who already holds System privilege to trigger an out-of-bounds write through a missing bounds check, yielding high impact to confidentiality, integrity and availability. No user interaction is required once System access is held, and the flaw is reachable in default configurations of the listed chipsets, making it a post-compromise escalation rather than an initial foothold; the CVSS 6.7 score is dominated by the PR:H prerequisite. A vendor patch is available under MediaTek's October 2026 Product Security Bulletin (patch ID ALPS11276677, issue MSV-9217), and no public exploit code or confirmed active exploitation has been identified at time of analysis.
An out-of-bounds read/write flaw in MediaTek's ccci (cross-core/modem control) component allows an authenticated local attacker who already holds System privilege to corrupt memory, potentially leading to information disclosure, crashes, or further privilege escalation. Exploitation requires local access and, per the vendor description, user interaction - though the vendor CVSS vector omits UI:R - and is limited to specific MediaTek chipsets (MT6880, MT6890, MT6980D, MT6990, MT6986, MT6986D, MT6813, MT6988, MT2735, MT2737). No public exploit code has been identified, SSVC reports exploitation: none and not automatable, making this a high-severity but low-urgency issue due to its high-privilege prerequisite.
Denial of service in MediaTek cellular modem firmware lets an attacker running a rogue base station crash the modem of an attached device by delivering a malformed message that triggers a missing bounds check, severing cellular connectivity until the modem restarts. The flaw is availability-only (CVSS 5.3, AV:A/AC:H/PR:N/UI:N/C:N/I:N/A:H) and is gated by radio proximity plus the victim UE actually attaching to the attacker-controlled cell, so it is not reachable over the internet and carries no confidentiality or integrity impact. No public exploit code and no confirmed active exploitation were identified at time of analysis, and MediaTek has shipped fixes (patch IDs MOLY01864925 / MOLY01210562) covering more than 50 chipsets across the October 2026 product security bulletin.
Denial of service in MediaTek's cellular modem firmware can crash the baseband on a broad set of MediaTek chipsets - including MT6991, MT6988, MT6897, MT8755, MT6835, MT8792 and others - causing the device to drop connectivity or reset. Exploitation is unauthenticated (PR:N, UI:N) but requires the attacker to operate a rogue, attacker-controlled base station and to get the target user equipment to attach to it over the radio interface, which is why attack complexity is rated high (AV:A/AC:H) and impact is limited to availability (A:H; no confidentiality or integrity effect). MediaTek publishes fix identifiers MOLY01870473 / MOLY00814393 (issue MSV-9041) in its October 2026 product security bulletin; no public exploit code and no confirmed active exploitation have been identified at time of analysis, and CISA's SSVC assessment rates exploitation as 'none' with partial technical impact, keeping real-world priority moderate-to-low despite the large number of affected chipsets.
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take the pinctrl mutex. This causes a gpiochip operations to need to sleep. Worse yet, the .can_sleep field in the gpiochip is not set. This causes the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check whether it can use a spinlock or needs a mutex. In this case, it ends up taking a spinlock, then calls pinctrl_gpio_direction_output(), which takes a mutex. This causes a huge warning. While this class of Mediatek hardware does not have separate clear/set registers, the pinctrl context has a spinlock that is taken whenever a register read-modify-write is done. Also, once the GPIO function is selected / muxed in, further GPIO operations do not involve pinctrl operations or state. The GPIO direction and level values do not require toggling the pinmux or any other pin config options. Switch to directly calling mtk_pinmux_gpio_set_direction() in the GPIO set direction callbacks to avoid taking the pinctrl mutex. Drop the .gpio_set_direction field in mtk_pmxops to signal we are no longer using the pinctrl GPIO layer for setting the direction.
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences in mt8365_afe_suspend() mt8365_afe_suspend() allocates the register backup buffer with devm_kcalloc(), but does not check for allocation failure before using the returned pointer. This may lead to a NULL pointer dereference when accessing afe->reg_back_up[i]. Add the missing NULL check and return -ENOMEM on allocation failure after disabling the main clock. Also propagate the return value of mt8365_afe_suspend() in mt8365_afe_dev_runtime_suspend() so that the suspended state is not updated when suspend fails.
In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip The gpio_chip is allocated with device-managed memory but registered with the non-managed gpiochip_add_data(). This was harmless while the drivers were built-in, but once they can be built as modules and unbound/rmmod'd, devm frees the gpio_chip's memory while it is still registered, causing a use-after-free. Register it with devm_gpiochip_add_data() so it shares the same device-managed lifecycle, which also lets the manual gpiochip_remove() error paths go away.
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: free EINT resources on unbind mtk_eint_do_init() creates an IRQ domain, populates it with a mapping for every EINT line and installs a chained handler on the parent interrupt, but none of these are ever released. This was harmless while the drivers were built-in, but now that they can be built as modules and unbound/rmmod'd it leaves behind a dangling IRQ domain, interrupt mappings whose chip data points at freed memory, and a chained handler that keeps firing into that freed data. The plain allocations in mtk_eint_do_init() already use the device-managed devm_*() helpers, so tear the remaining resources down the same way: register a devm action that detaches the chained handler, waits for any in-flight handler to finish, disposes of the per-line mappings and removes the IRQ domain. This mirrors the device-managed lifecycle adopted for the GPIO chip and keeps the whole EINT setup self-cleaning on unbind.
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: pllfh: Fix IO remapping leak in register_pllfhs error path When mtk_clk_register_pllfhs function fails to register a PLL, it unregisters all PLLs and cleans up itself in its error path before returning, so the function callers don't need to do it. But contrary to mtk_clk_unregister_pllfhs function, that does almost the same sequence, it does not free the IO memory mapped on fhctl node, leading to a leak. Fix this leak by factorizing the cleanup sequence in a new private function and use it both mtk_clk_register_pllfhs and mtk_clk_unregister_pllfhs functions. Also, change the loop index start value to avoid the -1 operation on index at each loop.
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Release reserved memory on cleanup The MT8192 AFE probe calls of_reserved_mem_device_init() and falls back to preallocated buffers when no reserved memory region is available. When the reserved memory assignment succeeds, however, the driver never releases it. Register a devm cleanup action after a successful reserved-memory assignment so the assignment is released on probe failure and driver unbind.
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8183: Release reserved memory on cleanup The MT8183 AFE probe can assign reserved memory with of_reserved_mem_device_init(), but the assignment is never released on driver removal or later probe failures. Register a devm cleanup action so the reserved memory assignment is released consistently, matching newer Mediatek AFE drivers.
In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check Should probe fail for HW_VOTER type power domains, this driver was unconditionally trying to perform cleanup for DIRECT_CTL domains, but only after checking if the target domain is powered on... with the DIRECT_CTL scpsys_domain_is_on() code again. And there's more: the scpsys_domain_is_on() function is also being unconditionally used in the probe path, for any power domain that has flag MTK_SCPD_KEEP_DEFAULT_OFF! This bug was never experienced by anyone because the HWV domains never failed probe, and because none of those is declared with the aforementioned flag - but it's still something critical. In order to fix this, add a check for MTCMOS Type and, based on that, call the correct functions for an "is on" check, and also do the same for the cleanup path, calling the correct functions for the "power off" action. For the latter, since there's a call to pm_genpd_remove() right before calling power_off, be cautious and add a variation of the power off functions (with a _internal suffix) for those to get a pointer to scpsys_domain instead of one to generic_pm_domain as, even if that's still working, this is way too much fragile and would break at some point.
In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series.
The Linux kernel's mediatek-gen3 PCIe host controller driver (mtk_pcie_setup_irq()) allocates IRQ domains before fetching the controller's own IRQ, so when that IRQ lookup fails the function returns early and leaves the allocated domains unreleased. Only systems built with CONFIG_PCIE_MEDIATEK_GEN3 and running on MediaTek SoC hardware contain the affected code, and the error path is not attacker-controlled under normal operation - reaching it requires local, high-privileged access capable of driving the driver's probe into the IRQ-not-found condition, with the assessed outcome being a low-severity local availability impact (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L). No public exploit has been identified at time of analysis, EPSS is 0.16% (6th percentile), and vendor fixes are published for the 6.1, 6.6, 6.12, 6.18, 7.0 and 7.1 branches.
Firmware crash in the Linux kernel's mt76/mt7921 WiFi driver allows a local low-privileged user to cause denial of service by triggering station Association ID (AID) values above the firmware's undocumented limit of 20. Affected hardware includes Mediatek mt7922 chipsets operating in AP mode (IFTYPE_AP). Exploitation requires running a non-standard hostapd configuration that allocates AIDs starting at 65 or higher - stock hostapd is not affected. No public exploit has been identified and EPSS is 0.16% (5th percentile), indicating very low exploitation likelihood.
Improper access control in the MediaTek Audio HAL on Samsung Mobile Devices running Android 14, 15, and 16 permits local unprivileged attackers to invoke restricted privileged functions within the audio subsystem. The CVSS 4.0 subsequent system impact is rated High across confidentiality, integrity, and availability (SC:H/SI:H/SA:H), indicating that successful exploitation can cascade well beyond the Audio HAL itself to compromise broader device system components. No public exploit identified at time of analysis; Samsung has released a fix in SMR Jun-2026 Release 1.
Memory exhaustion via the MediaTek SVS (Smart Voltage Scaling) debugfs interface in the Linux kernel allows a local attacker with low privileges to leak kernel memory on MediaTek SoC-based systems. The root cause is that `svs_enable_debug_write()` allocates a buffer via `memdup_user_nul()` to copy user-supplied input, but fails to free it when the subsequent `kstrtoint()` call rejects non-integer input - a classic CWE-401 missing-release flaw. No public exploit has been identified and EPSS is 0.02% (7th percentile), making this a low-urgency, patch-when-convenient issue for the narrow device population running affected MediaTek SoC kernels.
NULL pointer dereference in the Linux kernel's MediaTek DSI DRM driver causes a kernel panic during module initialization on ARM64 systems with MediaTek display hardware. The crash occurs because `mipi_dsi_host_register` triggers the `mtk_dsi_bind` callback before the `mtk_dsi` struct is stored in driver data, dereferencing a NULL pointer inside `drm_mode_object_add` and acquiring `mode_config.idr_mutex` before panicking - blocking all subsequent DRM operations on the system. No public exploit exists and EPSS stands at 0.02%, consistent with a hardware-specific local denial-of-service with no confidentiality or integrity impact.
The Nbiot SDK's wlan STA driver contains a buffer overflow vulnerability due to missing bounds checking that allows privilege escalation from System-level access. An attacker with existing System privileges can exploit this flaw without user interaction to gain elevated permissions. No patch is currently available for this vulnerability.
Improper input validation in Modem firmware (Nr16, Nr15, Nr17r, Nr17) enables remote denial of service attacks when devices connect to attacker-controlled base stations. An unauthenticated attacker can trigger a system crash without user interaction or special privileges. No patch is currently available for this vulnerability.
The Nr15 modem is susceptible to a denial-of-service attack through improper input validation when connecting to a rogue base station, allowing an attacker to trigger a system crash without requiring user interaction or special privileges. An unauthenticated attacker within radio proximity can exploit this vulnerability to render affected modems unresponsive. No patch is currently available for this issue.
Improper error handling in the modem component of Nr15, Nr16, and Nr17 devices enables denial of service attacks when a device connects to an attacker-controlled base station. An unauthenticated remote attacker can trigger a system crash without user interaction, and no patch is currently available. The vulnerability affects all Nr-series products with a CVSS score of 6.5.
An uncaught exception in WLAN AP/STA firmware for NBIoT SDK, OpenWrt, and related development kits enables adjacent network attackers to trigger a denial of service condition that renders the system unresponsive without requiring authentication or user interaction. The vulnerability affects multiple wireless products and has no available patch at this time, presenting a medium-severity risk in networked environments.
Nr15 versions up to - is affected by allocation of resources without limits or throttling (CVSS 6.5).
A missing bounds check in the Modem component affecting Nr17r, Nr16, Nr15, and Nr17 devices enables remote denial of service attacks when a user connects to an attacker-controlled base station, causing system crashes without requiring user interaction or elevated privileges. The vulnerability allows unauthenticated attackers on the same network segment to crash affected devices remotely. No patch is currently available for this vulnerability.
Denial of service attacks against Nr15, Nr16, and Nr17 modems are possible through improper input validation when a device connects to an attacker-controlled base station. An unauthenticated attacker can trigger a system crash without requiring user interaction or special privileges. No patch is currently available for this vulnerability.
Modem firmware versions Nr15, Nr16, Nr17, and Nr17r are susceptible to denial of service attacks due to insufficient bounds checking in memory operations. An attacker controlling a rogue base station can trigger a system crash on connected devices without requiring authentication or user interaction. No patch is currently available for this vulnerability.
The Nr15 Modem lacks proper input validation in message handling, allowing an attacker controlling a rogue base station to trigger a denial of service condition and crash the system without requiring user interaction or special privileges. This vulnerability affects any device connecting to the compromised base station and currently lacks a vendor patch.
In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: fix use-after-free on probe deferral The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors.
In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. [CVSS 6.5 MEDIUM]
In Modem, there is a possible system crash due to incorrect error handling. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. [CVSS 6.5 MEDIUM]
In Modem, there is a possible system crash due to incorrect error handling. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. [CVSS 6.5 MEDIUM]
Nr15 versions up to - is affected by improper check for unusual or exceptional conditions (CVSS 6.5).
In Modem, there is a possible read of uninitialized heap data due to an uncaught exception. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. [CVSS 6.5 MEDIUM]
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).
Broken AFBC (Arm Frame Buffer Compression) handling in the Linux kernel's Mediatek DRM driver on MT8188 (Genio 700) SoCs causes constant vblank timeouts and garbled display output when the 32x8/split/sparse AFBC modifier is used, which Mesa v25.0+ enables by default. A local user with GPU/display access can trigger a hung display pipeline (denial of service) and rendering of stale/garbled framebuffer contents (limited information disclosure). No public exploit identified at time of analysis, and EPSS is very low (0.17%, 7th percentile), consistent with a hardware-specific reliability bug rather than a widely weaponizable flaw.
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setup variable *nplanes is provided by user via system call argument. The possible value of q_data->fmt->num_planes is 1-3, while the value of *nplanes can be 1-8. The array access by index i can cause array out-of-bounds. Fix this bug by checking *nplanes against the array size.
In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01717526; Issue ID: MSV-5591.
In Modem, there is a possible system crash due to incorrect error handling. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01661189; Issue ID: MSV-4298.
In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01677581; Issue ID: MSV-4701.
In Modem, there is a possible out of bounds read due to a missing bounds check. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673760; Issue ID: MSV-4650.
In Modem, there is a possible system crash due to an uncaught exception. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673755; Issue ID: MSV-4647.
In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673751; Issue ID: MSV-4644.
In Modem, there is a possible system crash due to a logic error. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01673749; Issue ID: MSV-4643.