Alessandro Sangiorgi — GPU Performance Engineer

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

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

`iface.c`: The `ndo_bpf` Callback

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