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. Environment 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). Observed descriptor counts 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. Expected behavior 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: 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? The recommended ordering for releasing NDP and Wi-Fi Aware session resources so that the system can clean up all associated state? 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.