-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
sql: return expected user-facing error for invalid unnest arguments #110956
Conversation
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.
Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @michae2)
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.
Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @DrewKimball)
pkg/sql/logictest/testdata/logic_test/srfs
line 1428 at r1 (raw file):
statement error pgcode 42804 pq: could not determine polymorphic type: unnest\(unknown, unknown, unknown\) SELECT unnest(NULL, NULL, NULL);
Could you add the following testcases as well:
SELECT unnest('{1}'::int[], '{2}', '{3}');
SELECT unnest('{1}'::int[], '{}', '{}');
SELECT unnest('{1}', '{2}', '{3}'::int[]);
SELECT unnest('{}', '{}', '{3}'::int[]);
Previously, the `unnest` builtin function could trigger an internal error when passed multiple non array-type arguments. This is because it only checked whether the arguments were `NULL` when determining whether they were of a valid type. This is not a problem for some types, like `INT`, because they will prevent the function overloads from being resolved. However, since `TEXT` arguments can be cast to `ARRAY` types, function overload resolution succeeds. Since `unnest` only checked for `NULL`, it would assume that the arguments were array types, and attempt to retrieve the (nil) array contents. For the single-argument case this wasn't a problem because nil is used to signal invalid arguments, anyway. However, the multiple-argument case wraps the array contents of each argument type into a tuple, resulting in a tuple-type of nil types. This caused a nil-pointer dereference later down the line. This patch prevents the internal error by checking directly that the arguments are `ARRAY` types, to ensure that the array contents are non-nil. If the check fails, the (nil) `tree.UnknownReturnType` type is returned, which signals an invalid type. That results in an expected, user-facing error instead of an internal error. The `information_schema._pg_expandarray` builtin function had a similar vulnerability. This patch fixes that as well. Fixes cockroachdb#110952 Release note (bug fix): Fixed an edge case in the `unnest` and `information_schema._pg_expandarray` builtin functions that could cause an internal error when passed string arguments that could be cast to an array.
806f559
to
1f24340
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.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @michae2)
pkg/sql/logictest/testdata/logic_test/srfs
line 1428 at r1 (raw file):
Previously, michae2 (Michael Erickson) wrote…
Could you add the following testcases as well:
SELECT unnest('{1}'::int[], '{2}', '{3}'); SELECT unnest('{1}'::int[], '{}', '{}'); SELECT unnest('{1}', '{2}', '{3}'::int[]); SELECT unnest('{}', '{}', '{3}'::int[]);
Done.
TFTRs! bors r+ |
Build failed (retrying...): |
Build succeeded: |
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. error creating merge commit from 1f24340 to blathers/backport-release-22.2-110956: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.2.x failed. See errors above. error creating merge commit from 1f24340 to blathers/backport-release-23.1-110956: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 23.1.x failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
Previously, the
unnest
builtin function could trigger an internal error when passed multiple non array-type arguments. This is because it only checked whether the arguments wereNULL
when determining whether they were of a valid type. This is not a problem for some types, likeINT
, because they will prevent the function overloads from being resolved.However, since
TEXT
arguments can be cast toARRAY
types, function overload resolution succeeds. Sinceunnest
only checked forNULL
, it would assume that the arguments were array types, and attempt to retrieve the (nil) array contents. For the single-argument case this wasn't a problem because nil is used to signal invalid arguments, anyway. However, the multiple-argument case wraps the array contents of each argument type into a tuple, resulting in a tuple-type of nil types. This caused a nil-pointer dereference later down the line.This patch prevents the internal error by checking directly that the arguments are
ARRAY
types, to ensure that the array contents are non-nil. If the check fails, the (nil)tree.UnknownReturnType
type is returned, which signals an invalid type. That results in an expected, user-facing error instead of an internal error.The
information_schema._pg_expandarray
builtin function had a similar vulnerability. This patch fixes that as well.Fixes #110952
Release note (bug fix): Fixed an edge case in the
unnest
andinformation_schema._pg_expandarray
builtin functions that could cause an internal error when passed string arguments that could be cast to an array.