{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2025-39985",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2025-39985"
  ],
  "published": "2025-10-15T07:57:23Z",
  "summary": "can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow\n\nSending an PF_PACKET allows to bypass the CAN framework logic and to\ndirectly reach the xmit() function of a CAN driver. The only check\nwhich is performed by the PF_PACKET framework is to make sure that\nskb->len fits the interface's MTU.\n\nUnfortunately, because the mcba_usb driver does not populate its\nnet_device_ops->ndo_change_mtu(), it is possible for an attacker to\nconfigure an invalid MTU by doing, for example:\n\n  $ ip link set can0 mtu 9999\n\nAfter doing so, the attacker could open a PF_PACKET socket using the\nETH_P_CANXL protocol:\n\n\tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))\n\nto inject a malicious CAN XL frames. For example:\n\n\tstruct canxl_frame frame = {\n\t\t.flags = 0xff,\n\t\t.len = 2048,\n\t};\n\nThe CAN drivers' xmit() function are calling can_dev_dropped_skb() to\ncheck that the skb is valid, unfortunately under above conditions, the\nmalicious packet is able to go through can_dev_dropped_skb() checks:\n\n  1. the skb->protocol is set to ETH_P_CANXL which is valid (the\n     function does not check the actual device capabilities).\n\n  2. the length is a valid CAN XL length.\n\nAnd so, mcba_usb_start_xmit() receives a CAN XL frame which it is not\nable to correctly handle and will thus misinterpret it as a CAN frame.\n\nThis can result in a buffer overflow. The driver will consume cf->len\nas-is with no further checks on these lines:\n\n\tusb_msg.dlc = cf->len;\n\n\tmemcpy(usb_msg.data, cf->data, usb_msg.dlc);\n\nHere, cf->len corresponds to the flags field of the CAN XL frame. In\nour previous example, we set canxl_frame->flags to 0xff. Because the\nmaximum expected length is 8, a buffer overflow of 247 bytes occurs!\n\nPopulate net_device_ops->ndo_change_mtu() to ensure that the\ninterface's MTU can not be set to anything bigger than CAN_MTU. By\nfixing the root cause, this prevents the buffer overflow.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.155",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/0fa9303c4b9493727e0d3a6ac3729300e3013930"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/37aed407496bf6de8910e588edb04d2435fa7011"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6eec67bfb25637f9b51e584cf59ddace59925bc8"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ca4e51359608e1f29bf1f2c33c3ddf775b6b7ed1"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3664ae91b26d1fd7e4cee9cde17301361f4c89d5"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6b9fb82df8868dbe9ffea5874b8d35f951faedbb"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/b638c3fb0f163e69785ceddb3b434a9437878bec"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T12:19:11Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - Exploitation is performed entirely with local syscalls on the host owning the CAN interface \u2014 `socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))` plus `sendmsg()`, optionally preceded by an rtnetlink MTU change. No remote or adjacent-network peer can reach `mcba_usb_start_xmit()`; the USB dongle and the CAN bus are only the sink for the resulting transfer, never the source of the malicious frame.\nAC:L - The overflow is fully deterministic \u2014 a single crafted CAN XL frame with `flags = 0xff` unconditionally makes `cf->len` 255 and drives a 255-byte `memcpy()` into an 8-byte stack field, with no race, no timing window, and no dependence on memory layout to trigger.\nPR:L - The minimal variant needs only `ns_capable(net->user_ns, CAP_NET_RAW)` from `packet_create()` because a 13\u201316 byte CAN XL skb already fits under the default `CAN_MTU`, and the fully-controlled-payload variant adds only the namespaced `CAP_NET_ADMIN` for the MTU change; CAN netdevs are not netns-local, so a `can0` delegated into a container or user namespace puts both capabilities in the hands of an unprivileged user, and typical container runtimes grant `CAP_NET_RAW` by default.\nUI:N - The attacker performs every step alone \u2014 open the packet socket, optionally set the MTU, and send the malicious CAN XL frame. No victim action, mount, or file open is involved.\nS:U - The corruption stays in kernel stack and adjacent heap memory within the same kernel security authority as the attacking process; no VM, hypervisor, IOMMU, or sandbox boundary is crossed.\nC:H - With a minimal 13-byte skb permitted at the default MTU, the `memcpy()` reads 255 bytes from a much smaller skb data area, over-reading ~247 bytes of adjacent kernel heap, and 8 of those bytes are copied into the URB and DMA'd out to the USB device as an externally observable disclosure primitive; the stack corruption itself further yields arbitrary-read capability.\nI:H - Up to 247 bytes are written past an 8-byte array in a 19-byte stack struct, overwriting the stack canary, saved registers and return address of `mcba_usb_start_xmit()`, and with the MTU raised those bytes are entirely attacker-chosen \u2014 a classic control-flow hijack and arbitrary-write primitive suitable for privilege escalation.\nA:H - The stack smash trips the stack protector (`__stack_chk_fail` panic) or corrupts the transmitting task's frame in the xmit path, reliably producing a kernel oops or panic, and it can be re-triggered at will from an unprivileged socket."
    }
  }
}