Postgres image `17.6.1.106` segfaults on `permission denied` for reserved roles (`authenticated`, `anon`)

[TobCar]

TL;DR

In ghcr.io/supabase/postgres:17.6.1.106, calling any function on which EXECUTE has been revoked from authenticated (or anon) crashes the backend with signal 11: Segmentation fault instead of raising 42501 permission denied for function. The previous image 17.6.1.095 raises the error correctly. The crash brings the entire Postgres instance into recovery mode, breaking all subsequent connections.

This appears to be in supautils' permission-denied path for reserved/hint_roles. It does not reproduce when the same operation is attempted by a non-reserved role.

Environment

• Image: ghcr.io/supabase/postgres:17.6.1.106 (also reproduces under public.ecr.aws/supabase/postgres:17.6.1.106)
• Server: PostgreSQL 17.6 on aarch64-unknown-linux-gnu, compiled by gcc (GCC) 15.2.0, 64-bit
• Supabase CLI: 2.90.0
• Started via: supabase start (default config, no extra extensions enabled in supabase/config.toml)
• shared_preload_libraries: pg_stat_statements, pgaudit, plpgsql, plpgsql_check, pg_cron, pg_net, pgsodium, auto_explain, pg_tle, plan_filter, supabase_vault
• supautils.hint_roles: anon, authenticated, service_role
• supautils.reserved_roles includes authenticated*, anon*, service_role*

Minimal reproduction

-- Trivial function, default search_path, security invoker — content is irrelevant.
create or replace function public.repro()
returns int
language sql
as $$ select 1; $$;

revoke all on function public.repro() from public, anon, authenticated;

set role authenticated;
select public.repro();

Expected

ERROR:  permission denied for function repro

Actual

server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to server was lost

Postgres logs:

LOG:  server process (PID 836) was terminated by signal 11: Segmentation fault
DETAIL:  Failed process was running: select public.repro();
LOG:  terminating any other active server processes
LOG:  all server processes terminated; reinitializing
LOG:  database system was not properly shut down; automatic recovery in progress

After recovery, all subsequent connections fail with FATAL: the database system is in recovery mode until Postgres finishes recovery.

Scope

Reproduces on:

• set role authenticated; select public.<revoked_fn>();
• set role anon; select public.<revoked_fn>();
• Both SECURITY DEFINER and SECURITY INVOKER functions
• Functions whose body is trivially select 1; — body is never executed

Does not reproduce on:

• set role service_role; select public.<revoked_fn>(); (function executes normally; service_role wasn't denied)
• A non-reserved login role with the same revoke (create role test_revoke_user login; grant test_revoke_user to postgres; set role test_revoke_user; select public.<revoked_fn>();) — this correctly raises ERROR: permission denied for function.

The differentiating factor between crash and clean error is whether the calling role is one of the supautils-managed reserved/hint_roles.

Regression range

Image	Behavior
17.6.1.095	Clean 42501 permission denied
17.6.1.106	SIGSEGV, full instance recovery cycle

17.6.1.095 was the default for at least Supabase CLI versions through ~2.89.x; 2.90.0 defaults to 17.6.1.106. CI using supabase/setup-cli@v1 with version: latest started failing the moment the bump landed.

Real-world impact in our repo

Every pgTAP test of the form

set local role authenticated;
select throws_ok(
  $$ select public.<service_role_only_rpc>(...) $$,
  '42501', null,
  'authenticated cannot execute <rpc>'
);

crashes the backend, takes down the entire test run, and leaves Postgres in recovery for several seconds. Every PR's supabase test db job has been failing since the image bump.

[t-weis]

A couple of additional findings from my own investigation of this that might help narrow things down:

Likely root cause: supautils PR #178

supautils 3.2.0 (supabase/supautils#178, "feat: add hint when GRANT privilege is missing", merged 2026-03-12) introduced an ExecutorStart_hook that intercepts ERRCODE_INSUFFICIENT_PRIVILEGE and appends a GRANT ... hint. It's gated to supautils.hint_roles (default: anon, authenticated, service_role) — which matches the exact set of roles that crash here. supautils 3.2.0 is the version that first shipped in supabase/postgres:17.6.1.100.

Verified working on .098, broken on .100

• 17.6.1.098 - clean 42501 permission denied
• 17.6.1.100 - SIGSEGV (first broken version)
• 17.6.1.107 - SIGSEGV

Fully standalone reproduction

docker run -d --name segfault_test -e POSTGRES_PASSWORD=postgres \
  public.ecr.aws/supabase/postgres:17.6.1.107

docker exec segfault_test psql -U postgres -c "
CREATE FUNCTION public.f() RETURNS void LANGUAGE sql AS \$\$SELECT\$\$;
REVOKE ALL ON FUNCTION public.f() FROM PUBLIC, authenticated, anon, service_role;
SET ROLE authenticated;
SELECT public.f();
"

Non-reserved roles don't crash

Creating a non-reserved role with identical attributes to authenticated (NOLOGIN INHERIT, same statement_timeout rolconfig) and running the same revoke + SET ROLE + call does not crash — consistent with the crash being gated to supautils.hint_roles membership rather than any role attribute.

docker run -d --name segfault_test -e POSTGRES_PASSWORD=postgres \
  public.ecr.aws/supabase/postgres:17.6.1.107

docker exec segfault_test psql -U postgres -c "
CREATE ROLE testuser NOLOGIN INHERIT;
ALTER ROLE testuser SET statement_timeout = '8s';
GRANT testuser TO postgres;

CREATE FUNCTION public.f() RETURNS void LANGUAGE sql AS \$\$SELECT\$\$;
REVOKE ALL ON FUNCTION public.f() FROM PUBLIC, authenticated, anon, service_role, testuser;
"

# Non-reserved role: clean 42501.
docker exec segfault_test psql -U postgres -c "
SET ROLE testuser;
SELECT public.f();
"
# ERROR:  permission denied for function f

# Reserved role: same function, same ACL — SIGSEGV.
docker exec segfault_test psql -U postgres -c "
SET ROLE authenticated;
SELECT public.f();
"
# server closed the connection unexpectedly