SHMEM_ATTACH_UNKNOWN_SIZE reaches InitShmemIndexEntry()

[pg-hub-mirror]

Read-only mirror. Reply and review on pgsql-hackers; activity here is not sent upstream.

• Original author: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
• Mailing list: pgsql-hackers
• Message-ID: CAExHW5u_fTsOAS85kG981Vu6eR1GV-344rup6zYew7xMjEDREw@mail.gmail.com
• Original email

Patch files:

• v20260918-0001-Attaching-to-a-non-existing-shared-memory-.patch

---

Hi All, Heikki,
SHMEM_ATTACH_UNKNOWN_SIZE can be passed as argument to
ShmemRequestStruct() when the caller wants to attach to an existing
shared memory structure, whose size it does not know, after the
startup. If the shared memory structure it wants to attach to does not
exist, the request should fail. But instead
ProcessShmemRequestsAfterStartup() ended up creating the structure
with size = -1. InitShmemIndexEntry() did not catch it and created a
ShmemIndexEntry with size = SIZE_MAX since size is an unsigned
integer. ShmemAllocRaw() did not catch the overflow in address
arithmetic and ended up allocating the new structure overlapping the
earlier structure which can potentially cause memory corruption.
Attached patch fixes ProcessShmemRequestsAfterStartup() throw an error
in this case, adds an Assert() in InitShmemIndexEntry() to make sure
that a request with unknown size never reaches it, makes
ShmemAllocRaw() check for overflow, and documents use of
SHMEM_ATTACH_UNKNOWN_SIZE.
I found this problem when working on resizable shared structures where
the size of the structure may have changed from its initial size and
hence may not be known. It's good to defend our shared memory
structures from a bug in extension code.

Best Wishes,
Ashutosh Bapat

[pg-hub-mirror]

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> via pgsql-hackers · original email

On 18/09/2026 10:00, Ashutosh Bapat wrote:

SHMEM_ATTACH_UNKNOWN_SIZE can be passed as argument to
ShmemRequestStruct() when the caller wants to attach to an existing
shared memory structure, whose size it does not know, after the
startup. If the shared memory structure it wants to attach to does not
exist, the request should fail. But instead
ProcessShmemRequestsAfterStartup() ended up creating the structure
with size = -1. InitShmemIndexEntry() did not catch it and created a
ShmemIndexEntry with size = SIZE_MAX since size is an unsigned
integer. ShmemAllocRaw() did not catch the overflow in address
arithmetic and ended up allocating the new structure overlapping the
earlier structure which can potentially cause memory corruption.

Attached patch fixes ProcessShmemRequestsAfterStartup() throw an error
in this case, adds an Assert() in InitShmemIndexEntry() to make sure
that a request with unknown size never reaches it, makes
ShmemAllocRaw() check for overflow, and documents use of
SHMEM_ATTACH_UNKNOWN_SIZE.

I found this problem when working on resizable shared structures where
the size of the structure may have changed from its initial size and
hence may not be known. It's good to defend our shared memory
structures from a bug in extension code.
Committed with minor cosmetic changes, thanks!

• Heikki