Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump postgresql driver to 42.3.3 #11449

Merged
merged 1 commit into from
Mar 14, 2022
Merged

Conversation

hashhar
Copy link
Member

@hashhar hashhar commented Mar 13, 2022

Description

It addresses CVE-2022-21724.

It also includes some fixes around calendars being used in thread-safe
way, result of PgObject#isNull, possible connection leak and loss of
microseconds when reading TIME(6) via getTimestamp.

Documentation

(x) No documentation is needed.

Release notes

(x) Release notes entries required with the following suggested text:

# PostgreSQL
* Fix possible connection leak when connecting to PostgreSQL failed. ({issue}`11449`)

It addresses CVE-2022-21724.

It also includes some fixes around calendars being used in thread-safe
way, result of PgObject#isNull, possible connection leak and loss of
microseconds when reading TIME(6) via getTimestamp.
@cla-bot cla-bot bot added the cla-signed label Mar 13, 2022
@hashhar hashhar requested a review from ebyhr March 13, 2022 17:12
@hashhar hashhar merged commit 78eca2a into trinodb:master Mar 14, 2022
@hashhar hashhar deleted the hashhar/pgjdbc-bump branch March 14, 2022 06:29
@github-actions github-actions bot added this to the 374 milestone Mar 14, 2022
@findepi
Copy link
Member

findepi commented Mar 14, 2022

It also includes some fixes around calendars being used in thread-safe
way

Does this affect the connector?

possible connection leak

Does this affect the connector?

and loss of
microseconds when reading TIME(6) via getTimestamp.

it doesn't affect the connector, right?

@hashhar
Copy link
Member Author

hashhar commented Mar 14, 2022

The connection leak does affect us, I was able to reproduce it by setting low per-user connection limit in PostgreSQL. I saw open sockets even if connection attempt failed. The connection does get cleaned up eventually but under load it seems very much possible to have idle sockets.

The calendar thread-safety issue is possible to hit by sharing connections across threads - I couldn't find existing code that does this though.

The loss of microseconds doesn't affect us since we don't use getTimestamp - sorry for keeping it in the commit message.

(All of this context could've gone to the commit message 😞 )

@findepi
Copy link
Member

findepi commented Mar 14, 2022

The calendar thread-safety issue is possible to hit by sharing connections across threads - I couldn't find existing code that does this though.

the connector doesn't do that (and shouldn't)

The connection leak does affect us, I was able to reproduce it by setting low per-user connection limit in PostgreSQL.

Let's have this in RNs.

v-jizhang added a commit to v-jizhang/presto that referenced this pull request Mar 23, 2022
Cherry-pick of trinodb/trino#11449

It addresses CVE-2022-21724.
Presto uses version 42.2.5 which is in the affected versions
(>= 9.4.1208, < 42.2.25).

It also includes some fixes around calendars being used in thread-safe
way, result of PgObject#isNull, possible connection leak and loss of
microseconds when reading TIME(6) via getTimestamp.

Co-authored-by: Ashhar Hasan <[email protected]>
rschlussel pushed a commit to prestodb/presto that referenced this pull request Apr 5, 2022
Cherry-pick of trinodb/trino#11449

It addresses CVE-2022-21724.
Presto uses version 42.2.5 which is in the affected versions
(>= 9.4.1208, < 42.2.25).

It also includes some fixes around calendars being used in thread-safe
way, result of PgObject#isNull, possible connection leak and loss of
microseconds when reading TIME(6) via getTimestamp.

Co-authored-by: Ashhar Hasan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants