Skip to content

fix(array): validate MakeFromData type IDs#904

Open
fallintoplace wants to merge 1 commit into
apache:mainfrom
fallintoplace:pr/fix-makefromdata-typeid-bounds
Open

fix(array): validate MakeFromData type IDs#904
fallintoplace wants to merge 1 commit into
apache:mainfrom
fallintoplace:pr/fix-makefromdata-typeid-bounds

Conversation

@fallintoplace

@fallintoplace fallintoplace commented Jul 4, 2026

Copy link
Copy Markdown
Contributor

Summary

Fail fast on invalid Arrow type IDs in array.MakeFromData instead of masking and dispatching into the wrong constructor slot.

Why this fix

MakeFromData currently masks the type ID (& 0x3f) before table lookup. New or invalid IDs can wrap to valid indices, causing wrong constructors or nil dispatch and a confusing panic.

Changes

  • Convert ID to int and validate it explicitly.
  • Reject IDs that are:
    • less than zero
    • greater/equal to len(makeArrayFn)
    • mapped to nil constructors
  • Keep existing invalidDataType(...) panic path for unsupported IDs.

Files

  • arrow/array/array.go
  • arrow/array/array_test.go

Validation

  • Added TestMakeFromData case for invalid type 64 and assertion of panic text.

Bug details

  • Severity: 88/100
  • Ask product?: 0/100

@zeroshade zeroshade left a comment

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.

Correct fix — the old & 0x3f mask silently wrapped type IDs ≥ 64 onto the wrong constructor. One small nit inline.

Comment thread arrow/array/array.go
return makeArrayFn[byte(data.DataType().ID()&0x3f)](data)
id := int(data.DataType().ID())
if id < 0 || id >= len(makeArrayFn) || makeArrayFn[id] == nil {
invalidDataType(data)

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.

Nit: prefer return invalidDataType(data) here. As written it relies on invalidDataType panicking as a side effect; returning it is clearer and stays correct even if that helper is ever changed to return a sentinel/typed error instead of panicking (otherwise execution would fall through to makeArrayFn[id](data) with an invalid id).

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