DF-2540 — Signed integer overflow in amdsb_watchdog() timeout calculation

Verdict

NOT REPRODUCED on this guest (HW-gated — no AMD SB600/SB7xx southbridge in QEMU). However, the code bug is CONFIRMED by source tracing and arithmetic verification: the signed integer overflow at line 217 produces a watchdog count of 0 for specific period values, bypassing the max-ticks clamp and programming the hardware to fire immediately.

Bug analysis

amdsb_watchdog() (sys/dev/misc/amdsbwd/amdsbwd.c:211-228):

static int
amdsb_watchdog(void *arg, int period)
{
    unsigned int timeout;
    struct amdsbwd_softc *sc = arg;

    timeout = (period * 1000) / sc->ms_per_tick;   // line 217: SIGNED overflow
    if (timeout > sc->max_ticks)                    // line 218: clamp — can't undo overflow
        timeout = sc->max_ticks;
    ...
    amdsbwd_tmr_set(sc, timeout);                   // programs hardware count register
    return period;
}

period is int (from kern.watchdog.period sysctl). period * 1000 is int × int → int. For period > INT_MAX/1000 = 2147483, this overflows signed int — undefined behavior in C. On two's-complement hardware (gcc 8.3 default), it wraps.

With sc->ms_per_tick = 1000 (the only value assigned, amdsbwd.c:472):

period = 4294967: 4294967 * 1000 = 4294967000, which as int32 wraps to -296. Then -296 / 1000 = 0 (C integer division truncates toward zero, and |-296| < 1000). timeout = (unsigned int)0 = 0. Since 0 <= max_ticks(65535), the clamp does NOT fire. amdsbwd_tmr_set(sc, 0) programs the AMD SB watchdog count register to 0, causing the watchdog to fire immediately → deterministic system reboot.

The finding's analysis is correct: the signed overflow produces count=0 for period ≈ 4294967, bypassing the clamp and causing an immediate reboot on real AMD SB hardware.

Why it can't be reproduced on this guest

The amdsbwd device only attaches when AMD SB600/SB7xx/SB8x hardware is present (amdsbwd_identify checks pci_find_bsf(0, 20, 0) for AMD SMBus device IDs at amdsbwd.c:245-251). The QEMU guest uses an Intel 440FX / PIIX3 chipset — no AMD SB device exists:

$ ls /dev/amdsbwd*          → No such file or directory
$ pciconf -lv | grep AMD    → (nothing — Intel 440FX/PIIX3/PIIX4 only)

Without the device, amdsb_watchdog is never registered as a watchdog_list callback, so kern.watchdog.period changes never reach the vulnerable code. The bug is latent on this guest — real on physical AMD SB hardware, unreachable in QEMU.

Impact

• CVSS PR:H — kern.watchdog.period requires root to set.
• HW-gated — requires AMD SB600/SB7xx/SB8x southbridge.
• On real hardware: root sets kern.watchdog.period=4294967 → AMD SB watchdog count=0 → immediate reboot. Local DoS via arithmetic logic bug.
• Not remotely exploitable; not unprivileged.

Fix

Cast period to int64_t before multiplication to eliminate the signed overflow:

-   timeout = (period * 1000) / sc->ms_per_tick;
+   timeout = ((int64_t)period * 1000) / sc->ms_per_tick;

With the fix, period=4294967 → (int64_t)4294967 * 1000 = 4294967000 (fits in int64), /1000 = 4294967, > max_ticks(65535) → clamped to 65535. Correct.

Validated: amdsbwd.ko rebuilt with the fix (make KERNCONF=X86_64_GENERIC in sys/dev/misc/amdsbwd/, rc=0). Behavioral testing not possible (no AMD SB hardware in QEMU); fix correctness is verified by arithmetic.