SHMEM_ATTACH_UNKNOWN_SIZE reaches InitShmemIndexEntry()

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)databricks(dot)com>
Subject: SHMEM_ATTACH_UNKNOWN_SIZE reaches InitShmemIndexEntry()
Date: 2026-09-18 07:00:13
Message-ID: CAExHW5u_fTsOAS85kG981Vu6eR1GV-344rup6zYew7xMjEDREw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v20260918-0001-Attaching-to-a-non-existing-shared-memory-.patch text/x-patch 7.1 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message 王红岩 2026-09-18 07:05:52 [PATCH v1] Use RVV for bounded NUL scans in pq_getmsgstring
Previous Message Alexander Korotkov 2026-09-18 06:48:13 Re: Reject WAIT FOR earlier in transaction-snapshot mode