[PATCH v2] mailbox: Prevent out-of-bounds access in of_mbox_index_xlate()

Joonwon Kang posted 1 patch 1 week, 6 days ago
There is a newer version of this series
drivers/mailbox/mailbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH v2] mailbox: Prevent out-of-bounds access in of_mbox_index_xlate()
Posted by Joonwon Kang 1 week, 6 days ago
Although it is guided that `#mbox-cells` must be at least 1, there are
many instances of `#mbox-cells = <0>;` in the device tree. If that is
the case and the corresponding mailbox controller does not provide
`of_xlate` function pointer, `of_mbox_index_xlate()` will be used by
default and out-of-bounds accesses could occur due to lack of bounds
check in that function.

Below is a problematic control flow when `#mbox-cells = <0>;`.

```
static struct mbox_chan *
of_mbox_index_xlate(struct mbox_controller *mbox,
                    const struct of_phandle_args *sp)
{
    int ind = sp->args[0];                                      // (4)

    if (ind >= mbox->num_chans)                                 // (5)
        return ERR_PTR(-EINVAL);

    return &mbox->chans[ind];                                   // (6)
}

struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
{
    struct of_phandle_args spec;                                // (1)

    if (of_parse_phandle_with_args(dev->of_node, "mboxes",      // (2)
        "#mbox-cells", index, &spec)) {
        ...
    }

    list_for_each_entry(mbox, &mbox_cons, node)
        if (mbox->dev->of_node == spec.np) {
            chan = mbox->of_xlate(mbox, &spec);                 // (3)
            if (!IS_ERR(chan))
                break;
        }
    ...
    ret = __mbox_bind_client(chan, cl);                         // (7)
    ...
}

static int __mbox_bind_client(struct mbox_chan *chan,
                              struct mbox_client *cl)
{
    if (chan->cl || ...) {                                      // (8)
}
```

(1) `spec.args[]` is filled with arbitrary leftover values in the stack.
    Let's say that `spec.args[0] == 0xffffffff`.
(2) Since `#mbox-cells = <0>;`, `spec.args_count` is assigned 0 and
    `spec.args[]` are untouched.
(3) Since the controller does not provide `of_xlate`,
    `of_mbox_index_xlate()` is used instead.
(4) `idx` is assigned -1 due to the value of `spec.args[0]`.
(5) Since `mbox->num_chans >= 0` and `idx == -1`, this condition does
    not filter out this case.
(6) Out-of-bounds address is returned. Depending on what was left in
    `spec.args[0]`, it could be an arbitrary(but confined to a specific
    range) address.
(7) A function is called with the out-of-bounds address.
(8) The out-of-bounds address is accessed.

This commit prevents the issue by checking the array bounds.

Signed-off-by: Joonwon Kang <joonwonkang@google.com>
---
 drivers/mailbox/mailbox.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 5cd8ae222073..5bccdf27d6ab 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -476,7 +476,7 @@ of_mbox_index_xlate(struct mbox_controller *mbox,
 {
 	int ind = sp->args[0];
 
-	if (ind >= mbox->num_chans)
+	if (sp->args_count < 1 || ind >= mbox->num_chans)
 		return ERR_PTR(-EINVAL);
 
 	return &mbox->chans[ind];
-- 
2.51.0.384.g4c02a37b29-goog
Re: [PATCH v2] mailbox: Prevent out-of-bounds access in of_mbox_index_xlate()
Posted by Jassi Brar 1 week, 6 days ago
On Thu, Sep 18, 2025 at 7:55 AM Joonwon Kang <joonwonkang@google.com> wrote:
>
> Although it is guided that `#mbox-cells` must be at least 1, there are
> many instances of `#mbox-cells = <0>;` in the device tree. If that is
> the case and the corresponding mailbox controller does not provide
> `of_xlate` function pointer, `of_mbox_index_xlate()` will be used by
> default and out-of-bounds accesses could occur due to lack of bounds
> check in that function.
>
OK, so we want of_mbox_index_xlate() to refuse if the channel's index
is not available, which
will be the case when #mbox-cells=<0> in dt and sp->args_count=0 here.
Fair enough.

I think the following details are unnecessary, maybe drop it.

Thanks