DF-0441 — CBQ rmc_newclass / rmc_modclass divide-by-zero
=======================================================

**Verdict:** REPRODUCED (panic / privileged local DoS).

Mechanism
---------
User-controlled `struct pf_altq.pq_u.cbq_opts.ns_per_byte` (a `u_int`, no
zero check) flows verbatim from a `DIOCADDALTQ`/`DIOCCHANGEALTQ` ioctl
through:

  altq_cbq.c:374    rmc_newclass(..., opts->ns_per_byte, ...)
  altq_rmclass.c:237    cl->allotment_ = RM_NS_PER_SEC / nsecPerByte;   <-- DIV0

The same pattern is at `altq_rmclass.c:350` in `rmc_modclass()`.

`pfctl` computes ns_per_byte from bandwidth ratios and won't produce 0
(pfctl_altq.c:465), but a malicious root can issue DIOCADDALTQ directly
with `cbq_opts.ns_per_byte = 0` and trigger the panic.

PoC
---
`cbq_div0.c` opens `/dev/pf`, starts pf + ALTQ, begins an altq transaction
(DIOCXBEGIN PF_RULESET_ALTQ), adds a CBQ discipline + a root class on
`vtnet0` (calls `rmc_init`, no div), then adds a non-root child class with
`cbq_opts.ns_per_byte = 0`.  The third DIOCADDALTQ calls `rmc_newclass`
which panics on the divide.

Trigger requires root: `/dev/pf` ioctls need root.  Privileged local DoS.

Reproduction
------------
On DragonFly 6.5-DEVELOPMENT #0 (unpatched baseline):

    # kldload pf.ko
    # ./cbq_div0
    altq ticket=1
    CBQ discipline added; altq_disc=0xfffff80118e63600
    Root class added; qid=1

    *** ABOUT TO ADD CHILD CLASS WITH ns_per_byte=0 -- EXPECT DIV0 PANIC ***

Panic signature (from dfbsd-qemu/boot.log, see panic.txt):

    Fatal trap 18: integer divide fault while in kernel mode
    cpuid = 4; lapic id = 4
    instruction pointer = 0x8:0xffffffff8072611a
    kernel: type 18 trap, code=0
    Stopped at  rmc_newclass+0x10a: divl %r9d,%eax

The IP `rmc_newclass+0x10a` matches the divide at altq_rmclass.c:237.

Fix validation
--------------
Applied `fix.diff` (clamps nsecPerByte to 1 if zero in both rmc_newclass
and rmc_modclass), rebuilt the kernel, rebooted into
6.5-DEVELOPMENT #1 (2026-07-18):

    # ./cbq_div0
    altq ticket=1
    CBQ discipline added; altq_disc=0xfffff80118592d00
    Root class added; qid=1
    *** ABOUT TO ADD CHILD CLASS WITH ns_per_byte=0 -- EXPECT DIV0 PANIC ***
    UNEXPECTED: child class added without panic (qid=2)
    RUN_EXIT=0

The previously-panicking child-class add now succeeds (nsecPerByte clamped
to 1 by the fix).  No panic, no trap.  Fix is VALIDATED.

Notes
-----
The fix clamps to 1 ns/byte instead of returning EINVAL, because the CBQ
config path is several layers deep and returning an error mid-transaction
would require unwinding the altq state.  Clamping is the cheapest correct
behavior: allotment_ becomes RM_NS_PER_SEC (1 byte/sec in some unit
interpretation), which is a safe degenerate value.