Gh-142174: Explicitly disallow `_as_parameter_` returning tuples by CodeMaverick-143 · Pull Request #142175 · python/cpython · GitHub
Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions Lib/test/test_ctypes/test_parameters.py
Empty file.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't put your name in the filename. If you'd like to get credit, you can add something like "Patch by Your Name." at the end of the entry.

Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra newline.

Analysis confirms that :mod:`ctypes` does not support returning tuples from ``_as_parameter_`` for default conversions. Attempting to do so raises a :exc:`TypeError` (wrapped in a ``ctypes.ArgumentError``), meaning the described security risk does not exist in the current codebase.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This NEWS entry is too verbose and if returning tuples from _as_parameter_ wasn't already supported and the change is only a redundant comment removal, then no NEWS is needed.

12 changes: 8 additions & 4 deletions Modules/_ctypes/callproc.c
Original file line number Diff line number Diff line change
Expand Up @@ -620,9 +620,6 @@ PyType_Spec carg_spec = {
* by value, or a 2-tuple or 3-tuple which will be used according
* to point 2 above. The third item (if any), is ignored. It is normally
* used to keep the object alive where this parameter refers to.
* XXX This convention is dangerous - you can construct arbitrary tuples
* in Python and pass them. Would it be safer to use a custom container
* datatype instead of a tuple?
*
* 4. Other Python objects cannot be passed as parameters - an exception is raised.
*
Expand Down Expand Up @@ -742,6 +739,13 @@ static int ConvParam(ctypes_state *st,
attribute)
*/
if (arg) {
if (PyTuple_Check(arg) || PyList_Check(arg)) {
Py_DECREF(arg);
PyErr_Format(PyExc_TypeError,
"Don't know how to convert parameter %d",
Py_SAFE_DOWNCAST(index, Py_ssize_t, int));
return -1;
}
int result;
Comment on lines +742 to 749

@picnixz picnixz Dec 3, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a good check IMO. This shouldn't be checked at this level, it should ConvParam that should be responsible (and the recursive call should be enough). I don't unedrstand why we have this additional check here.

result = ConvParam(st, arg, index, pa);
Py_DECREF(arg);
Expand Down Expand Up @@ -1512,7 +1516,7 @@ static void *libsystem_b_handle;
static bool (*_dyld_shared_cache_contains_path)(const char *path);

__attribute__((constructor)) void load_dyld_shared_cache_contains_path(void) {
libsystem_b_handle = dlopen("/usr/lib/libSystem.B.dylib", RTLD_LAZY);
libsystem_b_handle = dlopen("/usr/lib/libSystem.B.dylib", RTLD_LAZY | RTLD_GLOBAL);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this looks unrelated as well.

if (libsystem_b_handle != NULL) {
_dyld_shared_cache_contains_path = dlsym(libsystem_b_handle, "_dyld_shared_cache_contains_path");
}
Expand Down
4 changes: 3 additions & 1 deletion Objects/object.c
Loading