Wi-Fi Aware: wifip2pd accumulates netpolicy descriptors until reaching its 256-FD limit

I am investigating an iOS Wi-Fi Aware issue in which wifip2pd accumulates netpolicy file descriptors until it reaches its 256-FD limit. After this point, new Wi-Fi Aware pairing / NDP setup attempts fail.

• Device: iPhone 18 Pro Max
• OS: iOS 27.0 (24A8428)
• The issue was noticed during repeated Wi-Fi Aware pairing, NDP establishment, data transfer, and session release on November 3, 2026, around 18:34 (UTC+8).

A complete sysdiagnose captured during the failure at 19:54:44 (UTC+8) contains the following taskinfo entry:

process: "wifip2pd" [285]
file descriptors: 256 (vnode: 3, socket: 9, netpolicy: 243, nexus: 1)

The old wifip2pd process terminated at 19:54:59, and a new instance started shortly afterward. A second complete sysdiagnose captured the following day, after that restart, shows:

process: "wifip2pd" [20455]
file descriptors: 27 (vnode: 3, socket: 9, netpolicy: 14, nexus: 1)

The recovery coincided with the wifip2pd restart and Wi-Fi power transitions. The available logs do not isolate which user action triggered the restart, so I am not claiming a specific recovery procedure.

Descriptors associated with completed sessions should be released or reused. Repeated Wi-Fi Aware session setup and teardown should not leave wifip2pd unable to allocate further descriptors.

So far I have observed this only once and do not yet have a minimal or deterministic reproduction. I also cannot yet prove which API or session object retains the descriptors.

I have privately filed Feedback FB25442154 with the original, complete sysdiagnose captures from the failure and recovery states. I am not attaching those archives to this public post.

Could Apple Engineering please advise on:

1. Whether there are known iOS 27.0 issues in which wifip2pd retains netpolicy descriptors after Wi-Fi Aware / NDP teardown, and which component owns their lifecycle?
2. The recommended ordering for releasing NDP and Wi-Fi Aware session resources so that the system can clean up all associated state?
3. Any supported application-side mitigation, and the most useful additional logging or state to capture if this recurs?

I can provide further timing correlations or a focused reproduction privately through the Feedback if needed.