MagicStack / MagicStack/asyncpg
`Record.get()` with invalid positional argument count segfaults
还没有人认领这个 Issue。
- 主要语言
- Python
- 星标
- 8.1k
- 派生
- 468
- PR 合并指标
- 30 天内没有已合并 PR
描述
Calling asyncpg.Record.get() with an invalid number of positional arguments can crash the Python process instead of raising TypeError.
Confirmed crashing calls:
record.get()record.get("a", 2, 3)
Valid and separately handled cases behave as expected:
record.get("a")returns the value.record.get("a", default=2)raisesTypeError: Record.get() takes no keyword arguments.
Affected Component
- File:
asyncpg/protocol/record/recordobj.c - Function:
record_get() - Method exposed as:
asyncpg.Record.get - Observed commit:
db8ecc2a38e16fb0c090aef6f5506547c2831c24
Impact
This is a native crash / process-level denial of service in the CPython extension. It is not a PostgreSQL wire-level remote issue by itself; it requires same-process Python code to call Record.get() with an invalid positional argument count. This can still matter for applications that expose generic object dispatch, plugins, scripting hooks, template helpers, or RPC-style method invocation over returned records.
Root Cause
In record_get(), the invalid positional argument-count branch sets a Python exception but continues execution:
if (nargs == 2) {
key = args[0];
defval = args[1];
} else if (nargs == 1) {
key = args[0];
} else {
PyErr_Format(PyExc_TypeError,
"Record.get() expected 1 or 2 arguments, got %zd",
nargs);
}
key is not initialized in that branch. The function then reaches:
res = record_item_by_name((ApgRecordObject *)self, key, &val);
As a result, an uninitialized PyObject *key is passed to record_item_by_name(), causing a native crash.
The release build also emits:
asyncpg/protocol/record/recordobj.c:702:11: warning: 'key' may be used uninitialized [-Wmaybe-uninitialized]
Steps to Reproduce
Build asyncpg from source:
git submodule update --init --recursive
python setup.py build_ext --inplace
Minimal repro without requiring a PostgreSQL server, using the same internal record helper used by tests/test_record.py:
PYTHONPATH=. python -u - <<'PY'
from asyncpg.protocol.protocol import _create_record as Record
r = Record({"a": 0}, (1,))
print("before")
r.get()
print("after")
PY
A three-positional-argument variant also crashes:
PYTHONPATH=. python -u - <<'PY'
from asyncpg.protocol.protocol import _create_record as Record
r = Record({"a": 0}, (1,))
print("before")
r.get("a", 2, 3)
print("after")
PY
A public API variant can be reproduced by fetching any row and then calling the invalid method form:
import asyncio
import asyncpg
async def main():
conn = await asyncpg.connect()
try:
row = await conn.fetchrow("select 1 as a")
row.get()
finally:
await conn.close()
asyncio.run(main())
Expected Result
Invalid positional argument counts should raise a Python exception, for example:
TypeError: Record.get() expected 1 or 2 arguments, got 0
and:
TypeError: Record.get() expected 1 or 2 arguments, got 3
Actual Result
On a release build, both invalid calls segfault:
before no args
Segmentation fault (core dumped)
before three args
Segmentation fault (core dumped)
Local verification exited with code 139 for both r.get() and r.get("a", 2, 3).
With ASAN, the invalid argument-count path produced:
AddressSanitizer:DEADLYSIGNAL
ERROR: AddressSanitizer: SEGV on unknown address
Suggested Fix
Return immediately after setting the argument-count error:
} else {
PyErr_Format(PyExc_TypeError,
"Record.get() expected 1 or 2 arguments, got %zd",
nargs);
return NULL;
}
It would also be useful to add regression coverage to tests/test_record.py::test_record_get:
with self.assertRaises(TypeError):
r.get()
with self.assertRaises(TypeError):
r.get("a", 2, 3)
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 asyncpg/protocol/record/recordobj.c 中的 record_get() 开始,然后检查 tests/test_record.py::test_record_get。使用文档中记录的 setup.py 命令构建 extension,并使用 internal record helper 重现零参数和三个参数的调用。当这两个无效调用都引发 TypeError 且不会导致进程崩溃,并且回归测试通过时,即表示完成。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- c, postgresql, python
- 领域
- backend, databases
- Issue 类型
- 缺陷
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 活跃度
- 冷清
- 描述清晰度
- 描述清楚
- 新手友好度
- 88/100