PostgreSQL 11.4 fixes SCRAM parsing on servers and clients

Authentication code processes input from both sides of a connection. PostgreSQL 11.4 fixes a buffer-overflow hazard that illustrates this two-sided exposure. An authenticated database user could supply a crafted password value to the server, while a rogue server could send a crafted SCRAM authentication message to a client using libpq.

The June 20 announcement explains why the project issued this update outside its normal schedule. CVE-2019-10164 was serious enough to distribute the fix promptly. PostgreSQL 10 and 11 are affected, along with the PostgreSQL 12 beta. The repair requires attention to installed client libraries as well as the running server.

I value PostgreSQL's explicit release instructions in cases like this. A database installation includes programs that connect to it, and those programs can have security exposure independent of the server process. Treating the server version as the complete upgrade inventory would miss an affected component named in this advisory.

Password changes are untrusted input

The 11.4 release notes describe the server defect as a buffer-overflow hazard in SCRAM verifier parsing. An authenticated user could trigger a stack-based overflow by changing their own password to a purpose-crafted value. The consequences include a server crash and the possibility of arbitrary code execution as the PostgreSQL operating-system account.

The prerequisite is an authenticated user, not a database superuser. That is an important distinction for systems that allow several users to connect with limited SQL privileges. The authority to change one's own password does not imply authority to corrupt server memory or execute code as the service account.

Password processing must therefore preserve the boundary between an account-management operation and server execution. A value can enter through a legitimate administrative statement while remaining untrusted parser input. Authentication has established who submitted the request, but it has not made the request's contents safe for memory operations.

The announcement does not describe this as a defect in every supported branch. It identifies versions 10 and 11 and the 12 beta as affected. Older supported branches receive maintenance updates at the same time, but their presence in the announcement is not evidence that they share this particular vulnerability.

This makes version-specific reading necessary. A headline listing several maintenance releases combines the distribution of ordinary fixes with the urgency of a security repair whose scope is narrower. The announcement explicitly recommends prompt upgrades for the affected versions and the next scheduled downtime for other users.

A client also parses authentication messages

The libpq issue reverses the direction of trust. A rogue server could send a specifically crafted message during SCRAM authentication and cause the client to crash or potentially execute arbitrary code. In that case, the relevant operating-system identity is the account running the client application.

This matters because authentication is an exchange. A client that sends credentials also receives and interprets messages. Code on that receiving path has to handle malformed input even when the process on the other end claims to be a database server.

The advisory consequently requires upgrading libpq installations. Replacing the database server's executable does not replace copies of a client library installed with other applications. The release instructions name both tasks because the same security issue has consequences in separate processes on potentially different machines.

There is no basis in the announcement for assuming that an application avoids the problem merely because its own SQL is fixed. The client-side input involved is an authentication message sent by the server. Query construction and authentication-message parsing concern different inputs at different stages of a connection.

My preference is to treat database clients as maintained software in their own right. This release gives a concrete reason for that position. The code that an application uses to establish trust can itself be the code processing hostile input, and the affected client runs under the application's operating-system account.

Runtime pruning also receives correctness fixes

The security issue explains the release timing, but the maintenance changes address other material failures. Runtime partition pruning could produce wrong answers when a pruning comparison value was determined dynamically. The notes also identify cases involving multiple range-partitioned columns and stable comparison operators.

Pruning is an optimization only when it excludes data that cannot contribute to the answer. An erroneous exclusion changes the result of the query. These repairs therefore concern SQL correctness, even though they occur in machinery whose purpose is to avoid unnecessary work.

The release also changes how pg_dump recreates partitions. It now uses CREATE TABLE followed by ALTER TABLE ... ATTACH PARTITION, instead of including PARTITION OF in the creation command. The notes explain that this avoids unwanted changes to column order when matching the parent table.

Separating creation and attachment also allows the partition to be restored as a standalone table when its parent is absent. The later attachment fails in that scenario, but the table itself remains restorable. This is a useful example of dump output preserving an object's independent representation before reconstructing its relationship with another object.

Replacing binaries does not repair every existing index

An additional fix prevents an invalid empty B-tree page after a failure while processing included columns during a page split. Normal index operations might continue to work, while a later vacuum encounters the invalid page. The notes instruct affected users to reindex the specific index.

That instruction differs from the ordinary maintenance installation procedure. Updating binaries prevents the faulty path from creating the problem again, but an already affected index needs reconstruction. A release can therefore require both replacing software and repairing an object that the earlier software left behind.

The announcement says a dump and reload or pg_upgrade is unnecessary for this maintenance update. It also explicitly retains the reindex requirement for affected indexes. These statements address different kinds of work and are compatible. The central security instruction remains to upgrade and restart affected servers and upgrade their libpq installations, while the index repair applies where the documented vacuum errors reveal an existing invalid page.