{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-89738",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-89738"
  ],
  "published": "2026-09-11T19:47:07Z",
  "summary": "usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed\n\nIn polled-VBUS mode (board.vbus_pin && board.vbus_polled), probe arms a\nself-restarting cycle: at91_vbus_timer() schedules vbus_timer_work, and\nat91_vbus_timer_work() calls at91_vbus_update() and re-arms the timer via\nmod_timer(). Both recover the same udc through container_of and dereference\nit on every iteration.\n\nNeither teardown path cancels this cycle. udc is devm-allocated, so it is\nfreed after at91udc_remove() returns, and is likewise freed when probe\nfails and devres runs. A timer callback or work item that is pending or\nrunning at either point dereferences the freed udc.\n\nAdd at91_udc_shutdown_vbus_timer() and call it from at91udc_remove() and\nfrom the usb_add_gadget_udc() failure path in probe; the remaining probe\nerror paths fail before the timer is armed. timer_shutdown_sync() waits\nfor a running callback and clears timer->function, which makes the work\nhandler's mod_timer() a permanent no-op; cancel_work_sync() then drains\nany pending or running work whose re-arm attempt now does nothing. The\ntimer must be shut down first, since cancelling the work alone would let\nthe timer re-queue it. The guard mirrors probe: in IRQ mode the timer and\nwork_struct are never initialized.\n\nThis does not require a fault; a normal driver unbind can interleave with\nan already queued work item.\n\nThis issue was found by an in-house static analysis tool.",
  "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": null,
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89738"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/a2a602cb1e28d76a5398cec3fa21b0110385f501"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/51a311eb97e91ce1aed3005cb71ccb2e30f8cce8"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/557ef547d49ff5e6026a4d39bdd3113bd81d7688"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/c27d13ce4bab80fbdf6523928071b6c24b37606c"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-09-13T06:49:25Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The use-after-free is reached on local AT91 UDC platform-driver teardown (sysfs unbind, rmmod, or probe-error unwind after the polled-VBUS timer is armed), not by parsing USB host packets. That matches other USB gadget/UDC teardown UAFs scored Local and is higher severity than Physical.\nAC:L - Once polled-VBUS mode is active, unbind or the usb_add_gadget_udc() failure path frees the devm-allocated udc while the self-restarting timer/work still hold it; the next timer tick or already-queued work then dereferences the freed object with no race the attacker cannot drive.\nPR:L - Highest reasonable exposure is a local account that manages the USB gadget/UDC on AT91 industrial, IoT, and embedded controllers, where platform unbind or gadget HAL access is often delegated beyond init-namespace root. Uncertain Low vs High, so Low per the overestimate rule.\nUI:N - The attacker initiates driver unbind, module unload, or a failing re-probe themselves; no separate victim action such as plugging a USB cable, mounting a filesystem, or opening a device node is required.\nS:U - The use-after-free corrupts the host kernel's struct at91_udc heap object within the same OS security authority and does not cross a VM, IOMMU, or sandbox boundary.\nC:H - at91_vbus_timer() and at91_vbus_timer_work() recover the freed udc via container_of and read vbus_pin, gadget state, and related fields; reclaiming that slab yields a classic UAF read/disclosure primitive.\nI:H - The dangling work calls at91_vbus_session()/pullup(), which write MMIO through udp_baseaddr and invoke caps->pullup and possibly driver->disconnect on the freed object, enabling heap corruption and control-flow hijack.\nA:H - Dereferencing the freed udc from timer or workqueue context causes a kernel oops or panic even without a full exploit, so availability impact is High."
    }
  }
}