Skip to content

Conversation

@dmitry-lipetsk
Copy link
Contributor

@dmitry-lipetsk dmitry-lipetsk commented Jul 6, 2024

After the refactoring of the user managament in #1052, we incorrectly freed credentials by calling slab_free on a user_cache, instead of credentials_cache in two places. This could later cause segfaults because ththe user type is larger than the credentials type, so out of bound reads would be possible when the credential that was put into the user_cache was taken out again and used as a user instead.

kill_database must call slab_free(credentials_cache, db->forced_user_credentials) but not slab_free(user_cache, ...).

Because db->forced_user_credentials is allocated with slab_alloc(credentials_cache).

See force_user_credentials function.
…ser_cache

credentials_node_release is used only with PgDatabase::user_tree.

PgDatabase::user_tree is filled in add_dynamic_credentials.

add_dynamic_credentials allocates new credentials through slab_alloc(credentials_cache).

So, credentials_node_release must use slab_free(credentials_cache, user).
@dmitry-lipetsk dmitry-lipetsk changed the title Fix for #1104 [free db->forced_user_credentials] Fix for #1104 [free PgCredentials] Jul 8, 2024
@JelteF
Copy link
Member

JelteF commented Jul 9, 2024

Oooff, that's not good... Thanks for this fix. Any chance you can add a test that triggers the reported crash?

@emelsimsek @eulerto I think this is probably worth a patch release after this is merged. Let's not merge any other (non-critical) PRs so we can create that patch release directly from the master brach.

@JelteF
Copy link
Member

JelteF commented Jul 9, 2024

Ah I see now that you added the test in #1114, could you move that test here?

If "test_qa_gh1104" is not OK, please change it with any another correct name.
@dmitry-lipetsk
Copy link
Contributor Author

dmitry-lipetsk commented Jul 9, 2024

Cirrus CI / Linux (Debian/Ubuntu) CFLAGS:-O0 -g ENABLE_VALGRIND:yes PGVERSION:17

FAILED test/test_misc.py::test_qa_gh1104 - Failed: Timeout >30.0s

--- WIN-FIX1104
Cirrus CI / Windows -- Fix for #1104 [free PgCredentials]

https://github.com/pgbouncer/pgbouncer/pull/1105/checks?check_run_id=27239176206

FAILED test/test_misc.py::test_qa_gh1104 - psycopg.OperationalError: connection failed: connection to server at "127.0.0.1", port 10227 failed: FATAL: not allowed

It is bad...

pgbouncer has fix for #1104.

--- WIN-FIX1103
Cirrus CI / Windows -- Proposal to fix #1103 [problem with pool_list and put_in_order]

https://github.com/pgbouncer/pgbouncer/pull/1106/checks?check_run_id=27239898084

FAILED test/test_auth.py::test_qa_gh1103__put_in_order - psycopg.OperationalError: connection failed: connection to server at "127.0.0.1", port 10208 failed: FATAL: not allowed

It is another test but it has the same problem.

pgbouncer has fix for #1103.

--- WIN-QA1104

Cirrus CI / Windows - QA test for issue #1104

https://github.com/pgbouncer/pgbouncer/pull/1114/checks?check_run_id=27215709319

FAILED test/qa/github/test_qa_gh001104.py::test_qa_gh001104 - psycopg.OperationalError: connection failed: connection to server at "127.0.0.1", port 10204 failed: FATAL: not allowed

QA test uses unmodified pgbouncer.


Source code has the one point with string "not allowed":

disconnect_client(client, true, "not allowed");

I think it is a reason for "not allowed" in test on Windows.

Will try.
Or it solves the problem with Windows or I will start testing this on my local Windows :)
@dmitry-lipetsk
Copy link
Contributor Author

Hello, I have a little problem with configuration of development environment on Windows to research and fix a problem in test_ga_gh1104.

So, any help with it will be appreciative.

auth_type = trust
admin_users = pgbouncer

It was tested on Windows and Ubuntu. Amen.
It is enough to crash.
@dmitry-lipetsk
Copy link
Contributor Author

Done.

@JelteF JelteF merged commit 6c8a1df into pgbouncer:master Jul 18, 2024
JelteF pushed a commit to JelteF/pgbouncer that referenced this pull request Aug 1, 2024
After the refactoring of the user managament in pgbouncer#1052, we incorrectly
freed credentials by calling `slab_free` on a user_cache, instead of
`credentials_cache` in two places. This could later cause segfaults
because ththe user type is larger than the credentials type, so out of
bound reads would be possible when the credential that was put into the
user_cache was taken out again and used as a user instead.

(cherry picked from commit 6c8a1df)
JelteF pushed a commit that referenced this pull request Aug 2, 2024
After the refactoring of the user managament in #1052, we incorrectly
freed credentials by calling `slab_free` on a user_cache, instead of
`credentials_cache` in two places. This could later cause segfaults
because ththe user type is larger than the credentials type, so out of
bound reads would be possible when the credential that was put into the
user_cache was taken out again and used as a user instead.

(cherry picked from commit 6c8a1df)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants