CVS commit: src/sys/dev/acpi
"Taylor R Campbell" <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.cvs |
|---|---|
| Message-ID | <[email protected]> |
Module Name: src Committed By: riastradh Date: Sun Jul 5 01:51:58 UTC 2026 Modified Files: src/sys/dev/acpi: acpi_mcfg.c Log Message: acpi(4): Reset mcfg_nsegs to zero if we couldn't find any valid ones. acpimcfg_probe initializes mcfg_nsegs to the number of segments in thef MCFG table, and allocates space at mcfg_segs for an array of segments, but leaves the array zero-initialized. Later, acpimcfg_init initializes the array with the valid segments, and _if there are any_, sets mcfg_nsegs to the number of valid ones. But _if there aren't any_, acpimcfg_init would leave mcfg_nsegs set to the amount of space allocated in the array, all zero-initialized. Later still, if PCI_RESOURCE is enabled, acpimcfg_configure_bus would, via acpimcfg_get_segment, search mcfg_segs[0..mcfg_nsegs) for an entry matching a PCI segment and bus number, and if they both happened to be zero, the first one would match...and acpimcfg_configure_bus would fish the (null!) seg->ms_bst out of the all-zero entry and feed it to bus_space_map which would proceed to barf on the null pointer. To avoid this, we simply have acpimcfg_init reset mcfg_nsegs to zero if there are no valid segments found (and free the array, because we have no further use for it). This doesn't explain why none of the segments were found to be valid -- perhaps there's a bug in or around acpi_mcfg.c, or perhaps the motherboard firmware on the affected hardware is wrong -- but it should make the failure mode a little more graceful like it was before without PCI_RESOURCE. PR kern/60411: x86 PCI_RESOURCE: null pointer dereference at boot To generate a diff of this commit: cvs rdiff -u -r1.32 -r1.33 src/sys/dev/acpi/acpi_mcfg.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.