GHSA-wwqh-7jm5-gj7w: free5GC's PCF npcf-policyauthorization POST /app-sessions panics on suppFeat=1 with missing AfRoutReq via nil pointer dereference
Summaryfree5GC's PCF `POST /npcf-policyauthorization/v1/app-sessions` handler panics on a single authenticated request whose `ascReqData.suppFeat == "1"` (enabling traffic-routing feature negotiation) and whose `medComponents` entries supply an `afAppId` but NO `AfRoutReq`. The create path then calls `provisioningOfTrafficRoutingInfo(smPolicy, appID, routeReq, ...)` with `routeReq == nil` and dereferences `routeReq.RouteToLocs` (and other fields) without a nil check, causing `runtime error: invalid memory address or nil pointer dereference`. Gin recovery converts the panic into `HTTP 500`.The trigger is a single valid authenticated request -- changing only `suppFeat` from `"0"` to `"1"` flips the same shape of POST from a normal `201 Created` into a panic-driven `500`.This endpoint requires a valid `npcf-policyauthorization` OAuth2 access token (PR:L). The PCF process is not killed (Gin recovers); the realized impact is per-request panic-DoS on the app-session create path.DetailsValidated against the PCF container in the official Docker compose lab.Source repo tag: `v4.2.1`PCF endpoint: `http://10.100.200.9:8000`Validation date: 2026-03-12Vulnerable handler path:In `provisioningOfTrafficRoutingInfo`, `routeReq.RouteToLocs`, `routeReq.UpPathChgSub`, and `routeReq.AppReloc` are dereferenced directly without a nil check. When `suppFeat` is `"0"` the traffic-routing branch is not entered and the same input shape returns `201 Created`; when `suppFeat` is `"1"` the branch is entered and the nil-deref fires.Code evidence (paths in `free5gc/pcf`):Affected route + dispatch: `NFs/pcf/internal/sbi/api_policyauthorization.go`Create handler path: `NFs/pcf/internal/sbi/processor/policyauthorization.go`Call site that passes nil `routeReq` into the traffic-routing helper: `NFs/pcf/internal/sbi/processor/policyauthorization.go`Panic site (nil deref of `routeReq.*` fields): `NFs/pcf/internal/sbi/processor/policyauthorization.go:1740`PoCReproduced end-to-end against the running PCF at `http://10.100.200.9:8000`.Obtain a valid `npcf-policyauthorization` token from NRF:Trigger the panic with a single valid authenticated POST whose `ascReqData.suppFeat == "1"`, `medComponents` supplies `afAppId`, and `AfRoutReq` is absent:Control comparison -- same request shape but `suppFeat="0"` -> normal `201 Created`:PCF container logs show the panic stack landing in `provisioningOfTrafficRoutingInfo` with `routeReq = 0x0`:ImpactNULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the create path passes `routeReq` straight into `provisioningOfTrafficRoutingInfo` without a nil check, even though `medComp.AfRoutReq` is optional and is nil for the demonstrated valid input shape. The control experiment with `suppFeat="0"` proves the request shape itself is otherwise valid.Gin recovery catches the panic, so the PCF process is NOT killed and other endpoints continue serving. The realized impact is per-request: any authenticated POST against this endpoint with `suppFeat="1"` and `medComponents.*.AfAppId` set but `AfRoutReq` absent returns `HTTP 500` with empty body and a stack trace in PCF logs.Any party that holds (or can obtain) a valid `npcf-policyauthorization` token can repeatedly drive this code path to sustain a per-request panic-DoS on the app-session create endpoint, with each panic costing more CPU + log writes than the intended controlled response would have.No Confidentiality impact (the response is `500` with empty body). No persistent Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation.Affected: free5gc v4.2.1.Upstream issue: https://github.com/free5gc/free5gc/issues/879
Upstream fix: https://github.com/free5gc/pcf/pull/65
CVSS v3.1: 6.5