Bug 1879651 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

In the Pernosco recording, the data of the `DataSourceSurface` passed to `FlipYDataSourceSurface` starts at 0x7f062b9fb000.

This address was previously made read-only by a [`PCanvas::SnapshotShmem`](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/gfx/layers/ipc/PCanvas.ipdl#89) IPDL message, when it calls `mmap` to map in the shmem handle it received. It passes that `mmap` call an address of 0, meaning that the kernel may choose any address it likes; it chooses the exact same address the `DataSourceSurface` was using, 0x7f062b9fb000. It should only do this if that address is unmapped, meaning that the `DataSourceSurface`'s buffer had previously been freed, leaving it dangling.
[Edit: the below makes it sound as if the `DataSourceSurface` is created first, and then the page protections get changed. I now believe the order is the opposite: the pages are mapped read-only in response to the `SnapshotShmem` message, and then the `DataSourceSurface` is created to point to them.]

In the Pernosco recording, the data of the `DataSourceSurface` passed to `FlipYDataSourceSurface` starts at 0x7f062b9fb000.

This address was previously made read-only by a [`PCanvas::SnapshotShmem`](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/gfx/layers/ipc/PCanvas.ipdl#89) IPDL message, when it calls `mmap` to map in the shmem handle it received. It passes that `mmap` call an address of 0, meaning that the kernel may choose any address it likes; it chooses the exact same address the `DataSourceSurface` was using, 0x7f062b9fb000. It should only do this if that address is unmapped, meaning that the `DataSourceSurface`'s buffer had previously been freed, leaving it dangling.
[Edit: the below makes it sound as if the `DataSourceSurface` is created first, and then the page protections get changed. I now believe the order is the opposite: the pages are mapped read-only in response to the `SnapshotShmem` message, and then the `DataSourceSurface` is created to point to them. The `DataSourceSurface`'s buffer never dangles: it was read-only from its creation.]

In the Pernosco recording, the data of the `DataSourceSurface` passed to `FlipYDataSourceSurface` starts at 0x7f062b9fb000.

This address was previously made read-only by a [`PCanvas::SnapshotShmem`](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/gfx/layers/ipc/PCanvas.ipdl#89) IPDL message, when it calls `mmap` to map in the shmem handle it received. It passes that `mmap` call an address of 0, meaning that the kernel may choose any address it likes; it chooses the exact same address the `DataSourceSurface` was using, 0x7f062b9fb000. It should only do this if that address is unmapped, meaning that the `DataSourceSurface`'s buffer had previously been freed, leaving it dangling.

Back to Bug 1879651 Comment 8