Integer overflow in maxAckBacklog on 32-bit when size is 32

In this file the external inputs are mainly:

- the `fd` passed to `unix.SetsockoptInt`
- the contents of `/proc/sys/net/core/somaxconn`
- the `uname.Release` string returned by `unix.Uname`

There is no packet parsing, no fixed-size buffer fill from untrusted data, no slice/array out-of-bounds issue, and no unchecked pointer dereference. The `fd` path is not a memory-safety bug: an invalid or non-socket fd should produce a kernel error from `SetsockoptInt`, which is checked.

The main issues are integer/truncation and host/OS-controlled-input issues around backlog calculation:

- `maxAckBacklog` computes `u := 1<<size - 1`. On 64-bit this is fine, but on 32-bit Go, when `size == 32`, `1 << 32` wraps to `0`, making `u == -1`. If `somaxconn > 65535`, the helper can return `-1`, which may later be used as a negative backlog.
- `kernelVersion` parses `uname.Release` with unbounded digit accumulation. A malformed or malicious release string can overflow `value` or produce an incorrect major/minor version, causing the wrong backlog width to be selected.
- `soMaxConn` reads the entire `/proc` file into memory before parsing. In normal Linux this file is tiny, but a malicious host/OS could make it large, causing unbounded memory allocation and O(n) processing.
- `enableFastOpen` may be using the wrong socket option/value for Fast Open backlog; this is a functional/socket-option issue rather than a memory-safety issue.

No remotely network-triggered memory-corruption zero-day is evident in this file.

```json
[
  {
    "severity": "low",
    "title": "Integer overflow in maxAckBacklog on 32-bit when size is 32",
    "function": "maxAckBacklog",
    "description": "When kernelVersion reports kernel >= 4.1, size is set to 32. On 32-bit Go, int is 32 bits, so u := 1<<size - 1 wraps to -1 because 1<<32 evaluates to 0. If /proc/sys/net/core/somaxconn is greater than 65535, maxAckBacklog can return -1. A caller that passes this value to listen() may receive an invalid or negative backlog, causing listener failure or denial of service. Triggering requires a 32-bit runtime plus host/OS-controlled somaxconn or uname values."
  },
  {
    "severity": "low",
    "title": "kernelVersion can overflow or misparse malformed uname.Release",
    "function": "kernelVersion",
    "description": "The parser accumulates digits from the 65-byte uname.Release buffer without a digit-count limit or overflow check. A malicious or malformed kernel release string can cause value to wrap, producing incorrect major/minor version values. This can select the wrong backlog width, potentially allowing an oversized backlog for older kernels or triggering the 32-bit negative-clamp bug in maxAckBacklog. It requires control of uname, not network input."
  },
  {
    "severity": "low",
    "title": "Unbounded read of /proc/sys/net/core/somaxconn",
    "function": "soMaxConn",
    "description": "os.ReadFile reads the entire file before trimming and parsing. If a hostile host or OS makes /proc/sys/net/core/somaxconn large or a symlink to a large file, the process performs an unbounded memory allocation and O(n) TrimSpace/Atoi work. On normal Linux this file is tiny, so this is a resource-exhaustion defect only under a malicious filesystem/kernel."
  },
  {
    "severity": "low",
    "title": "Possible TCP Fast Open socket-option misuse",
    "function": "enableFastOpen",
    "description": "The code sets SOL_TCP/TCP_FASTOPEN (0x17) with fastOpenQlen (16384). On Linux, TCP_FASTOPEN is normally a boolean option, while the Fast Open listener backlog option is TCP_FASTOPEN_QLEN (0x1c). Depending on the kernel, the call may be rejected or may fail to configure the intended Fast Open backlog. This is a functional/socket-option issue, not a memory-safety issue."
  }
]
```