fix(docker): parse a /proc port at 16 bits, not 32 (CodeQL alert 8)

[ako]

Closes CodeQL alert 8, go/incorrect-integer-conversion (high), at cmd/mxcli/docker/portowner_linux.go:121.

What it is

hexPort reads the port out of a /proc/net/tcp local_address field:

n, err := strconv.ParseUint(addr[i+1:], 16, 32)
...
return int(n), true

Parsing at 32 bits and narrowing to int is only correct where int is 64 bits. Measured with a GOARCH=386 binary (which runs on an amd64 host, so this is observed rather than argued):

input	width 32 (before)	width 16 (after)
0100007F:1F90	8080, true	8080, true
0100007F:FFFFFFFF @ 64-bit	4294967295, true	0, false
0100007F:FFFFFFFF @ 32-bit	-1, true	0, false

How bad it is

Not exploitable, and I'd rate it informational rather than high:

• the input is /proc/net/tcp, written by the kernel, which formats the port %04X — no value wider than 16 bits is ever there, and nothing user-supplied reaches this function;
• the consequence of a wrap would be p != port failing to match, so the port-owner lookup returns nothing and the guard falls back to its generic "port in use" message. No memory unsafety, no bypass;
• the 32-bit half is doubly unreachable today: the repo does not currently build for 386 at all (mdl/settingsoverlay/settingsoverlay.go:45 has 9007199254740992 as an untyped int constant).

Why fix it anyway

A TCP port is 16 bits, so 16 is simply the right width, and parsing at the target type's width moves the range check into the parser instead of leaving it as a rule the next caller has to remember. It's a one-token change, and the alert otherwise stays open.

Tests

Both new tests fail against the old parser at 64 bits — verified by reverting the fix:

--- FAIL: TestHexPort_RefusesAValueWiderThanAPort
    0100007F:FFFFFFFF: accepted as port 4294967295 — a port is 16 bits
    0100007F:80000000: accepted as port 2147483648 — a port is 16 bits
    0100007F:10000: accepted as port 65536 — a port is 16 bits
--- FAIL: TestParseListeningInodes_IgnoresAnOutOfRangePortField
    port 4294967295 matched a row whose port field is not a port: map[5555:true]

TestHexPort_RefusesAValueWiderThanAPort opens with the control that a real port (8080) still parses, so the fix can't pass by refusing everything. The out-of-range literal is written int(^uint32(0)) rather than 4294967295, which is not a valid int constant on a 32-bit build.

Symptom row appended to .claude/skills/fix-issue.md.

🤖 Generated with Claude Code