Re: [PATCH] dt-bindings: misc: add binding for Xilinx AXI-Stream FIFO

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

New issues:
- [High] The YAML binding incorrectly documents the FIFO depth properties as being in 'bytes', while the driver and hardware expect them in 'words'.
- [Medium] The schema omits valid hardware properties while enforcing `additionalProperties: false`, falsely restricting the device tree to only the properties the current driver implementation reads and causing valid hardware device trees to fail schema validation.
- [Medium] Hardware data width properties are artificially constrained to `const: 32` based on driver support rather than hardware capabilities.
- [Low] The previous text-based binding document was not removed.

Pre-existing issues:
- [Critical] A pre-existing use-after-free vulnerability occurs if the device is unbound while userspace holds an open file descriptor.
--

commit 1499d3b34c3ed26799e82ed6630ba1f50a8aec04
Author: Aditya Chari <adi25charis@gmail.com>

dt-bindings: misc: add binding for Xilinx AXI-Stream FIFO

The axis-fifo driver's compatible strings were undocumented, flagged
by checkpatch.pl as UNDOCUMENTED_DT_STRING. Add a devicetree
binding document describing the required properties
for drivers/staging/axis-fifo, derived from the properties
the driver reads via of_property_read_u32()
in axis_fifo_parse_dt().

> dt-bindings: misc: add binding for Xilinx AXI-Stream FIFO

[Severity: Low]
Should the previous text-based binding document be removed in this patch?

It looks like the legacy drivers/staging/axis-fifo/axis-fifo.txt binding
was left in the tree, leaving two conflicting sources of truth for the
same hardware compatible string.

> diff --git a/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml b/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml
> new file mode 100644
> index 0000000000000..8ef0adde32ad8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/xlnx,axi-fifo-mm-s.yaml

[ ... ]

> +  xlnx,axi-str-rxd-tdata-width:
> +    description:
> +      Width in bits of the AXI4-Stream receive data interface. Only a
> +      width of 32 is currently supported by the driver.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    const: 32
> +
> +  xlnx,axi-str-txd-tdata-width:
> +    description:
> +      Width in bits of the AXI4-Stream transmit data interface. Only a
> +      width of 32 is currently supported by the driver.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    const: 32

[Severity: Medium]
Should this schema describe the hardware capabilities rather than the software
limitations?

Over-constraining the schema to const: 32 based on current driver support
might cause validation errors for device trees that accurately represent
hardware synthesized with different bus widths.

> +  xlnx,rx-fifo-depth:
> +    description:
> +      Depth in bytes of the receive FIFO, as configured in the IP core.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +
> +  xlnx,tx-fifo-depth:
> +    description:
> +      Depth in bytes of the transmit FIFO, as configured in the IP core.
> +    $ref: /schemas/types.yaml#/definitions/uint32

[Severity: High]
Is it correct to document these properties as being in bytes?

Looking at the driver code, it evaluates the depth as word counts when checking
for overflow:

drivers/staging/axis-fifo/axis-fifo.c:axis_fifo_write() {
    ...
    if (words_to_write > (fifo->tx_fifo_depth - 4)) {
        ...
    }
    ...
}

If a devicetree author specifies the depth in bytes per the new YAML
documentation, could the driver load a value four times too large, allowing
out-of-bounds writes that might trigger a hardware transmit overrun error?

[ ... ]

> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - xlnx,axi-str-rxd-tdata-width
> +  - xlnx,axi-str-txd-tdata-width
> +  - xlnx,rx-fifo-depth
> +  - xlnx,tx-fifo-depth
> +  - xlnx,use-rx-data
> +  - xlnx,use-tx-data
> +
> +additionalProperties: false

[Severity: Medium]
Does this schema artificially restrict the devicetree by omitting valid
hardware properties?

The original text binding allowed properties such as xlnx,has-axis-tkeep
and interrupt-names. Because the schema enforces additionalProperties: false,
will running dt_binding_check on existing, valid device trees generated for
this IP result in false-positive validation errors?

[Severity: Critical]
This is a pre-existing issue, but does the driver have a use-after-free
vulnerability if the device is unbound while a userspace process holds an
open file descriptor?

In the driver, the axis_fifo structure is allocated with devm_kzalloc() and
I/O memory mapped with devm_platform_get_and_ioremap_resource():

drivers/staging/axis-fifo/axis-fifo.c:axis_fifo_probe() {
    ...
    fifo = devm_kzalloc(dev, sizeof(*fifo), GFP_KERNEL);
    ...
}

However, axis_fifo_remove() unregisters the character device without tracking
or waiting for active file descriptors to close:

drivers/staging/axis-fifo/axis-fifo.c:axis_fifo_remove() {
    ...
    misc_deregister(&fifo->miscdev);
    ...
}

If the device is unbound via sysfs while a userspace process keeps the char
device open, the driver core's devres cleanup automatically frees the fifo
structure and unmaps base_addr. Would subsequent read(), write(), or poll()
calls via the active file descriptor then access the freed fifo pointer and
unmapped I/O memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260621085209.52651-1-adi25charis@gmail.com?part=1