Replying to this email means your email address will be shared with the team that works on this product. https://issues.oss-fuzz.com/issues/481932457
Changed [email protected] added comment #4: I have conducted a thorough analysis of this issue and believe it represents a genuine production bug, not an invalid fuzzer finding. I have carefully compared the fuzzer against the production binary gpsdecode, and they share the same set of initialisation steps, despite the fuzzer calling some deep-linked functions. The following is a summary of my understanding after analysing the issue. Root Cause The issue originates in the greis_msg_SI() function within the GREIS driver, which reads the gpsdata.satellites_visible variable from the parsed session. This value originates from untrusted data, and the function blindly trusts this count without validating it against the actual buffer size. https://gitlab.com/gpsd/gpsd/-/blob/50153e3ea7c85158c2cd4c84a1579f95de24ff31/drivers/driver_greis.c#L357-374 static gps_mask_t greis_msg_SI(struct gps_device_t *session, unsigned char *buf, size_t len) { ...... gpsd_zero_satellites(&session->gpsdata); // FIXME: check against MAXCHANNELS? session->gpsdata.satellites_visible = len - 1; for (i = 0; i < session->gpsdata.satellites_visible; i++) { // This isn't really PRN, this is USI. Convert it. unsigned short PRN = getub(buf, i); session->gpsdata.skyview[i].PRN = PRN; ...... } The critical issue is that the untrusted gpsdata.satellites_visible value is used as the loop counter, continuously reading bytes from the untrusted buffer and storing them in the session. If gpsdata.satellites_visible is sufficiently large, the session data will be overwritten. Even though the session is now configured as a struct of structs rather than a union of structs, a sufficiently large gpsdata.satellites_visible value can still corrupt the entire session. In our OSS-Fuzz issue, this overwrites the last_controller variable in the session, causing a segmentation fault in the gpsd_poll function when the GREIS driver returns. https://gitlab.com/gpsd/gpsd/-/blob/50153e3ea7c85158c2cd4c84a1579f95de24ff31/gpsd/libgpsd_core.c STICKY(session->last_controller)) { Following my analysis, I agree that the fix suggested above is the optimal solution to this vulnerability. I have also sent an email to Gary, the maintainer of this project, to provide a much complete analysis and summary. _______________________________ Reference Info: 481932457 gpsd:FuzzDrivers: Crash in gpsd_poll component: Public Trackers > 1362134 > OSS Fuzz status: New reporter: [email protected] cc: [email protected], [email protected], [email protected], and 3 more collaborators: [email protected] type: Vulnerability access level: Limited visibility priority: P2 severity: S2 hotlist: Reproducible, Stability-Memory-MemorySanitizer retention: Component default Disclosure: May 6, 2026 Project: gpsd Reported: Feb 5, 2026 Generated by Google IssueTracker notification system.
