Summary

The FW_GTPMAP handler at fwdev.c:657-660 copies (sc->fc->topology_map->crc_len + 1) * 4 bytes out of sc->fc->topology_map to the user buffer. crc_len is a 16-bit field, so the count can be up to (65535+1)*4 = 262144 bytes, while topology_map is allocated as exactly sizeof(struct fw_topology_map) ≈ 1036 bytes (firewire.c:738). The kernel increments crc_len once per received self-id packet in fw_sidrcv (firewire.c:1143) without ever bounding it against the topology_map allocation. A malicious FireWire device (or a hardware/protocol bug that inflates sid_cnt) can drive crc_len well past the buffer size; the FW_GTPMAP ioctl then reads adjacent kernel heap into user memory.

Root cause

/* fwdev.c:657-660 — the bug */
case FW_GTPMAP:
    bcopy(sc->fc->topology_map, ap->a_data,
        (sc->fc->topology_map->crc_len + 1) * 4);
    break;

fwdev.c:658-659 unconditionally trusts topology_map->crc_len. topology_map is struct fw_topology_map (firewire.h:361-368) which has room for self_id[4*64] (256 entries). The kernel bumps crc_len for each valid self-id packet at firewire.c:1143 with no upper-bound check, and sid_cnt = len/8 at firewire.c:1124 is also unvalidated against the buffer. Once crc_len exceeds ~258, FW_GTPMAP reads past the topology_map allocation (kernel OOB read) and writes those leaked kernel heap bytes into the user's buffer.

Threat model & preconditions

• Attacker position: Local operator-group user for the FW_GTPMAP ioctl. A malicious or buggy FireWire device is needed to inflate crc_len (the user-side call only leaks the bytes the device already caused to be over-counted).
• Privileges gained or impact: 1. Kernel info leak (C:H) — when crc_len has been inflated, the user's FW_GTPMAP buffer receives kernel heap bytes that were never part of the topology map. 2. Kernel panic (A:H) — if crc_len is so large that the bcopy walks into an unmapped kernel page, the kernel page-faults.
• Required config or capabilities: Default kernel with firewire configured. Local operator-group membership. A malicious FireWire device on the bus (or a related bug that grows crc_len) is needed to inflate the count.
• Reachability: open("/dev/fwN", O_RDWR); ioctl(fd, FW_GTPMAP, &buf); once crc_len has been inflated by a malicious device.

Proof of concept

Triggering from the local side requires crc_len to already be inflated. Without a malicious device this is normally small (≤ ~258). The audit PoC therefore targets the user-side call to demonstrate the OOB read once crc_len is large; to fully exercise it you need either a software FireWire controller, an ICOM-style sbp tool that injects self-ids, or a second cooperating bug that grows crc_len:

/* df-fw-gtpmap-oob.c */
#include <fcntl.h>
#include <sys/ioctl.h>
#include <bus/firewire/firewire.h>
#include <stdio.h>

int main(void) {
    int fd = open("/dev/fw0", O_RDWR);
    if (fd < 0) { perror("open"); return 1; }
    /* Allocate generously so the bcopy can write a large payload back. */
    static unsigned char buf[65536 * 4];
    if (ioctl(fd, FW_GTPMAP, buf) < 0) { perror("FW_GTPMAP"); return 1; }
    /* On a benign system this returns ≤ sizeof(struct fw_topology_map) ≈ 1036 bytes.
     * If crc_len has been inflated, you receive kernel heap bytes beyond the
     * topology_map allocation. */
    unsigned int *p = (unsigned int *)buf;
    printf("crc_len field  = %u\n", p[0] >> 16);
    printf("bytes returned beyond topology_map allocation are kernel-heap leak.\n");
    return 0;
}

Build & run

cc -o df-fw-gtpmap-oob df-fw-gtpmap-oob.c   # may need -I/usr/src
./df-fw-gtpmap-oob

Expected output

On a system where crc_len has been inflated (by a malicious device or by trigger of the related *self_id = ... OOB write at firewire.c:1142 which writes past self_id[256]), the output shows non-zero bytes past offset ~1036 of buf, demonstrating kernel heap disclosure.

Impact

Local kernel heap disclosure of up to 256 KB per FW_GTPMAP call when crc_len has been inflated by a malicious FireWire device. Scope:Changed reflects the cross-domain leak (host kernel heap → FireWire bus). High complexity (requires device-side setup). Medium severity per "info leak of limited kernel memory".

Recommended fix

Cap the copy at the allocation size. The structure's max valid crc_len is 3 + 256 (header + max self_id entries); hard cap to sizeof(struct fw_topology_map)/4 - 1.

--- a/sys/bus/firewire/fwdev.c
+++ b/sys/bus/firewire/fwdev.c
@@ -657,7 +657,10 @@
        break;
    case FW_GTPMAP:
-       bcopy(sc->fc->topology_map, ap->a_data,
-           (sc->fc->topology_map->crc_len + 1) * 4);
+       {
+           u_int cl = sc->fc->topology_map->crc_len;
+           if (cl > sizeof(struct fw_topology_map)/4 - 1)
+               cl = sizeof(struct fw_topology_map)/4 - 1;
+           bcopy(sc->fc->topology_map, ap->a_data, (cl + 1) * 4);
+       }
        break;

Also fix fw_sidrcv (firewire.c:1136-1183) to bound the self-id loop at 4*64 entries and stop incrementing crc_len past that.

References

• sys/bus/firewire/fwdev.c:657-660 — FW_GTPMAP bcopy with unbounded count
• sys/bus/firewire/firewire.c:738 — topology_map allocation (sizeof(struct fw_topology_map))
• sys/bus/firewire/firewire.c:1124, 1142-1143 — crc_len increment in fw_sidrcv
• sys/bus/firewire/firewire.h:361-368 — struct fw_topology_map (room for 256 self_ids)
• CWE-125 Out-of-bounds Read
• CWE-129 Improper Validation of Array Index

Timeline

• 2026-07-14 Discovered during automated audit.