linux-kernel - Re: [PATCH v1] firmware: microchip: fix UL_IAP lock check in mpfs_auto_update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdW2vv5YGudOtU7fTMTafK-VAXqHhw2nFvG418-wavA0gQ@mail.gmail.com>
Date: Tue, 31 Dec 2024 11:38:58 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Valentina Fernandez <valentina.fernandezalanis@...rochip.com>
Cc: conor.dooley@...rochip.com, daire.mcnamara@...rochip.com, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] firmware: microchip: fix UL_IAP lock check in mpfs_auto_update_state()

Hi Valentina,

On Mon, Nov 18, 2024 at 4:56 PM Valentina Fernandez
<valentina.fernandezalanis@...rochip.com> wrote:
> To verify that Auto Update is possible, the mpfs_auto_update_state()
> function performs a "Query Security Service Request" to the system
> controller.
>
> Previously, the check was performed on the first element of the
> response message, which was accessed using a 32-bit pointer. This
> caused the bitwise operation to reference incorrect data, as the
> response should be inspected at the byte level. Fixed this by casting
> the response to a  u8 * pointer, ensuring the check correctly inspects
> the appropriate byte of the response message.
>
> Additionally, rename "UL_Auto Update" to "UL_IAP" to match the
> PolarFire Family System Services User Guide.
>
> Signed-off-by: Valentina Fernandez <valentina.fernandezalanis@...rochip.com>

Thanks for your patch, which is now commit 48808b55b07c3cea ("firmware:
microchip: fix UL_IAP lock check in mpfs_auto_update_state()") in v6.13-rc4.

> --- a/drivers/firmware/microchip/mpfs-auto-update.c
> +++ b/drivers/firmware/microchip/mpfs-auto-update.c
> @@ -402,10 +402,10 @@ static int mpfs_auto_update_available(struct mpfs_auto_update_priv *priv)
>                 return -EIO;
>
>         /*
> -        * Bit 5 of byte 1 is "UL_Auto Update" & if it is set, Auto Update is
> +        * Bit 5 of byte 1 is "UL_IAP" & if it is set, Auto Update is
>          * not possible.
>          */
> -       if (response_msg[1] & AUTO_UPDATE_FEATURE_ENABLED)
> +       if ((((u8 *)response_msg)[1] & AUTO_UPDATE_FEATURE_ENABLED))
>                 return -EPERM;
>
>         return 0;

Why is response_msg not a u8 pointer in the first place?

        u32 *response_msg __free(kfree) =
                kzalloc(AUTO_UPDATE_FEATURE_RESP_SIZE *
sizeof(*response_msg), GFP_KERNEL);

So AUTO_UPDATE_FEATURE_RESP_SIZE is the number of 32-bit words...

However:

        response->resp_size = AUTO_UPDATE_FEATURE_RESP_SIZE;

and drivers/mailbox/mailbox-mpfs.c::mpfs_mbox_rx_data():

        u16 num_words = ALIGN((response->resp_size), (4)) / 4U;

so response->resp_size is the number of bytes?

See also drivers/char/hw_random/mpfs-rng.c::mpfs_rng_read():

        struct mpfs_mss_response response = {
                .resp_status = 0U,
                .resp_msg = (u32 *)response_msg,
                .resp_size = RNG_RESP_BYTES
        };

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds