-
-
Notifications
You must be signed in to change notification settings - Fork 33k
gh-139283: correctly handle size
limit in cursor.fetchmany()
#139296
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
Conversation
b86282b
to
be39d9b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the issue is that Py_T_UINT
doesn't do the proper validation, I'd imagine that this is an issue in other places too. Have you considered adding a private _Py_T_UINT32
that does do the validation, so we can use it elsewhere?
Modules/_sqlite/cursor.c
Outdated
} | ||
|
||
/*[clinic input] | ||
@critical_section |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A critical section won't help us much, because nothing else in Cursor
uses a critical section at the moment. All other readers will race with the setter function. We also shouldn't use a critical section here -- a relaxed atomic for uint32 will be faster, but let's do that in a different PR where we fix any thread-safety issues of _sqlite
entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also shouldn't use a critical section here -- a relaxed atomic for uint32 will be faster
Well, it was faster to write the critical section. I'll remove the critical sections from this PR for now if you want to address other thread safeties separately.
There's an open issue for that and the API is not decided (see capi-workgroup/decisions#63). So I won't bother for that yet. |
7bb5b7a
to
248400d
Compare
The C API WG decides on public C API. We can add private APIs all we want. If we add |
The problem is that even with a private API, it would become too annoying in the end. I don't want to create a new private API that could later be changed to accomodate the public one. In particular, I don't want to design something that would be eventually changed. See #117031 for an initial work as well. So here, I really want to focus on fixing |
@ZeroIntensity Do you have other comments on this specific fix apart the extra API that I will not add here? (even a new private API will need tests and other things that are too much for this PR in particular, however considering the next release is soon, I want this to be fixed ASAP). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this seems fine otherwise. I really think we should look into adding a private API for this afterward, especially if this problem is present in other places.
Thanks @picnixz for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
pythonGH-139296) Passing a negative or zero size to `cursor.fetchmany()` made it fetch all rows instead of none. While this could be considered a security vulnerability, it was decided to treat this issue as a regular bug as passing a non-sanitized *size* value in the first place is not recommended. (cherry picked from commit bc172ee) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Sorry, @picnixz, I could not cleanly backport this to
|
GH-139441 is a backport of this pull request to the 3.14 branch. |
…hmany()` (pythonGH-139296) Passing a negative or zero size to `cursor.fetchmany()` made it fetch all rows instead of none. While this could be considered a security vulnerability, it was decided to treat this issue as a regular bug as passing a non-sanitized *size* value in the first place is not recommended. (cherry picked from commit bc172ee) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
GH-139444 is a backport of this pull request to the 3.13 branch. |
…hmany()` (pythonGH-139296) Passing a negative or zero size to `cursor.fetchmany()` made it fetch all rows instead of none. While this could be considered a security vulnerability, it was decided to treat this issue as a regular bug as passing a non-sanitized *size* value in the first place is not recommended. (cherry picked from commit bc172ee) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…hmany()` (pythonGH-139296) Passing a negative or zero size to `cursor.fetchmany()` made it fetch all rows instead of none. While this could be considered a security vulnerability, it was decided to treat this issue as a regular bug as passing a non-sanitized *size* value in the first place is not recommended. (cherry picked from commit bc172ee) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
GH-139444 is a backport of this pull request to the 3.13 branch. |
1 similar comment
GH-139444 is a backport of this pull request to the 3.13 branch. |
…hmany()` (pythonGH-139296) Passing a negative or zero size to `cursor.fetchmany()` made it fetch all rows instead of none. While this could be considered a security vulnerability, it was decided to treat this issue as a regular bug as passing a non-sanitized *size* value in the first place is not recommended. (cherry picked from commit bc172ee) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…hmany()` (pythonGH-139296) Passing a negative or zero size to `cursor.fetchmany()` made it fetch all rows instead of none. While this could be considered a security vulnerability, it was decided to treat this issue as a regular bug as passing a non-sanitized *size* value in the first place is not recommended. (cherry picked from commit bc172ee) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Using the legacy PyMemerDef API is problematic for writable fields:
Py_T_UINT
or any other unsigned type, usingobj.attr = -1
does NOT raise a ValueError for legacy purposes (part of the very large commit 89f507f).uint32_t
instead. Previously it was stored as anint
.fetchmany()
to be auint32_t
which I can decrement instead of having an additional counter.📚 Documentation preview 📚: https://cpython-previews--139296.org.readthedocs.build/