public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Mattijs Korpershoek <mkorpershoek@baylibre.com>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Tom Rini <trini@konsulko.com>,
	u-boot@lists.denx.de,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Marek Vasut <marek.vasut+renesas@mailbox.org>,
	Dmitrii Merkurev <dimorinny@google.com>
Subject: Re: Fwd: New Defects reported by Coverity Scan for Das U-Boot
Date: Wed, 24 Jul 2024 11:56:17 +0200	[thread overview]
Message-ID: <87o76n5d1a.fsf@baylibre.com> (raw)
In-Reply-To: <5329b5b4-b54d-4c4d-aedc-c21c3da5f9ee@gmx.de>

Hi Heinrich,

On mer., juil. 24, 2024 at 11:45, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

> On 24.07.24 11:21, Mattijs Korpershoek wrote:
>> Hi Tom,
>>
>> Thank you for the report.
>>
>> On mar., juil. 23, 2024 at 08:18, Tom Rini <trini@konsulko.com> wrote:
>>
>>> Here's the latest report.
>>>
>>> ---------- Forwarded message ---------
>>> From: <scan-admin@coverity.com>
>>> Date: Mon, Jul 22, 2024, 8:07 PM
>>> Subject: New Defects reported by Coverity Scan for Das U-Boot
>>> To: <tom.rini@gmail.com>
>>>
>>>
>>> Hi,
>>>
>>> Please find the latest report on new defect(s) introduced to Das U-Boot
>>> found with Coverity Scan.
>>>
>>> 8 new defect(s) introduced to Das U-Boot found with Coverity Scan.
>>> 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the
>>> recent build analyzed by Coverity Scan.
>>>
>>> New defect(s) Reported-by: Coverity Scan
>>> Showing 8 of 8 defect(s)
>>>
>>>
>>> ** CID 501795:  Insecure data handling  (TAINTED_SCALAR)
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 501795:  Insecure data handling  (TAINTED_SCALAR)
>>> /boot/bootmeth_android.c: 96 in scan_boot_part()
>>> 90      if (!is_android_boot_image_header(buf)) {
>>> 91              free(buf);
>>> 92              return log_msg_ret("header", -ENOENT);
>>> 93      }
>>> 94
>>> 95      priv->header_version = ((struct andr_boot_img_hdr_v0
>>> *)buf)->header_version;
>>>>>>      CID 501795:  Insecure data handling  (TAINTED_SCALAR)
>>>>>>      Passing tainted expression "*buf" to "dlfree", which uses it as an
>>> offset.
>>
>> scan_boot_part() generates this warning, but scan_vendor_boot_part()
>> does not.
>> Both functions follow a similar code flow.
>>
>> The only reason scan_boot_part() generates this warning, is because of
>> the downcast into struct andr_boot_img_hdr_v0.
>>
>> We can't change char* buf into struct andr_boot_img_hdr_v0 because we
>> need to be block aligned when calling blk_dread().
>>
>> Per my understanding tainted data means it comes from user input (which
>> is true for both scan_boot_part() and scan_vendor_boot_part() because
>> both read from eMMC, which can be consider "user input".
>>
>> Since I don't see any particular problem with this code I propose that
>> we ignore this warning.
>
> The warning is specifically about invoking free for the buffer that we
> have allocated via malloc(). Our implementation of malloc() and free()
> stores some meta-information about allocated buffers at a negative
> offset and we don't overwrite this area via blk_read().

Ok, so does that mean that you agree that this code is safe and we don't
need any further action to fix it?

>
>>
>>
>>> 96      free(buf);
>>> 97
>>> 98      return 0;
>>> 99     }
>>> 100
>>> 101     static int scan_vendor_boot_part(struct udevice *blk, struct
>>> android_priv *priv)
>>>
>>> ** CID 501794:  Memory - corruptions  (OVERRUN)
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 501794:  Memory - corruptions  (OVERRUN)
>>> /lib/tpm_tcg2.c: 640 in tcg2_measurement_init()
>>> 634             rc = tcg2_log_prepare_buffer(*dev, elog,
>>> ignore_existing_log);
>>> 635             if (rc) {
>>> 636                     tcg2_measurement_term(*dev, elog, true);
>>> 637                     return rc;
>>> 638             }
>>> 639
>>>>>>      CID 501794:  Memory - corruptions  (OVERRUN)
>>>>>>      Overrunning array "version_string" of 50 bytes by passing it to a
>>> function which accesses it at byte offset 63.
>>> 640             rc = tcg2_measure_event(*dev, elog, 0, EV_S_CRTM_VERSION,
>>> 641                                     strlen(version_string) + 1,
>>> 642                                     (u8 *)version_string);
>>> 643             if (rc) {
>>> 644                     tcg2_measurement_term(*dev, elog, true);
>>> 645                     return rc;
>>>
>>> ** CID 501793:  Insecure data handling  (TAINTED_SCALAR)
>>> /lib/tpm-v2.c: 909 in tpm2_allow_extend()
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 501793:  Insecure data handling  (TAINTED_SCALAR)
>>> /lib/tpm-v2.c: 909 in tpm2_allow_extend()
>>> 903             int rc;
>>> 904
>>> 905             rc = tpm2_get_pcr_info(dev, &pcrs);
>>> 906             if (rc)
>>> 907                     return false;
>>> 908
>>>>>>      CID 501793:  Insecure data handling  (TAINTED_SCALAR)
>>>>>>      Using tainted variable "pcrs.count" as a loop boundary.
>>> 909             for (i = 0; i < pcrs.count; i++) {
>>> 910                     if (tpm2_is_active_pcr(&pcrs.selection[i]) &&
>>> 911                         !tpm2_algorithm_to_len(pcrs.selection[i].hash))
>>> 912                             return false;
>>> 913             }
>>> 914
>>> 915             return true;
>>>
>>> ** CID 501792:  Control flow issues  (DEADCODE)
>>> /lib/efi_loader/efi_helper.c: 137 in efi_load_option_dp_join()
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 501792:  Control flow issues  (DEADCODE)
>>> /lib/efi_loader/efi_helper.c: 137 in efi_load_option_dp_join()
>>> 131             if (fdt_dp) {
>>> 132                     struct efi_device_path *tmp_dp = *dp;
>>> 133
>>> 134                     *dp = efi_dp_concat(tmp_dp, fdt_dp, *dp_size);
>>> 135                     efi_free_pool(tmp_dp);
>>> 136                     if (!dp)
>>>>>>      CID 501792:  Control flow issues  (DEADCODE)
>>>>>>      Execution cannot reach this statement: "return
>>> 9223372036854775817UL;".
>>> 137                             return EFI_OUT_OF_RESOURCES;
>>> 138                     *dp_size += efi_dp_size(fdt_dp) + sizeof(END);
>>> 139             }
>>> 140
>>> 141             *dp_size += sizeof(END);
>>> 142
>>>
>>> ** CID 501791:    (DEADCODE)
>>> /drivers/usb/gadget/ether.c: 2219 in eth_bind()
>>> /drivers/usb/gadget/ether.c: 2110 in eth_bind()
>>> /drivers/usb/gadget/ether.c: 2071 in eth_bind()
>>> /drivers/usb/gadget/ether.c: 2089 in eth_bind()
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 501791:    (DEADCODE)
>>> /drivers/usb/gadget/ether.c: 2219 in eth_bind()
>>> 2213                    out_ep->name, in_ep->name,
>>> 2214                    status_ep ? " STATUS " : "",
>>> 2215                    status_ep ? status_ep->name : ""
>>> 2216                    );
>>> 2217            printf("MAC %pM\n", pdata->enetaddr);
>>> 2218
>>>>>>      CID 501791:    (DEADCODE)
>>>>>>      Execution cannot reach the expression "rndis" inside this
>>> statement: "if (cdc || rndis)
>>>    printf(...".
>>> 2219            if (cdc || rndis)
>>> 2220                    printf("HOST MAC %02x:%02x:%02x:%02x:%02x:%02x\n",
>>> 2221                            dev->host_mac[0], dev->host_mac[1],
>>> 2222                            dev->host_mac[2], dev->host_mac[3],
>>> 2223                            dev->host_mac[4], dev->host_mac[5]);
>>> 2224
>>> /drivers/usb/gadget/ether.c: 2110 in eth_bind()
>>> 2104                    device_desc.bNumConfigurations = 2;
>>> 2105
>>> 2106            if (gadget_is_dualspeed(gadget)) {
>>> 2107                    if (rndis)
>>> 2108                            dev_qualifier.bNumConfigurations = 2;
>>> 2109                    else if (!cdc)
>>>>>>      CID 501791:    (DEADCODE)
>>>>>>      Execution cannot reach this statement: "dev_qualifier.bDeviceClass
>>> ...".
>>> 2110                            dev_qualifier.bDeviceClass =
>>> USB_CLASS_VENDOR_SPEC;
>>> 2111
>>> 2112                    /* assumes ep0 uses the same value for both speeds
>>> ... */
>>> 2113                    dev_qualifier.bMaxPacketSize0 =
>>> device_desc.bMaxPacketSize0;
>>> 2114
>>> 2115                    /* and that all endpoints are dual-speed */
>>> /drivers/usb/gadget/ether.c: 2071 in eth_bind()
>>> 2065
>>> 2066     #if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
>>> 2067            /*
>>> 2068             * CDC Ethernet control interface doesn't require a status
>>> endpoint.
>>> 2069             * Since some hosts expect one, try to allocate one anyway.
>>> 2070             */
>>>>>>      CID 501791:    (DEADCODE)
>>>>>>      Execution cannot reach the expression "rndis" inside this
>>> statement: "if (cdc || rndis) {
>>>    statu...".
>>> 2071            if (cdc || rndis) {
>>> 2072                    status_ep = usb_ep_autoconfig(gadget,
>>> &fs_status_desc);
>>> 2073                    if (status_ep) {
>>> 2074                            status_ep->driver_data = status_ep;     /*
>>> claim */
>>> 2075                    } else if (rndis) {
>>> 2076                            pr_err("can't run RNDIS on %s",
>>> gadget->name);
>>> /drivers/usb/gadget/ether.c: 2089 in eth_bind()
>>> 2083                    }
>>> 2084            }
>>> 2085     #endif
>>> 2086
>>> 2087            /* one config:  cdc, else minimal subset */
>>> 2088            if (!cdc) {
>>>>>>      CID 501791:    (DEADCODE)
>>>>>>      Execution cannot reach this statement: "eth_config.bNumInterfaces =
>>> 1;".
>>> 2089                    eth_config.bNumInterfaces = 1;
>>> 2090                    eth_config.iConfiguration = STRING_SUBSET;
>>> 2091
>>> 2092                    /*
>>> 2093                     * use functions to set these up, in case we're
>>> built to work
>>> 2094                     * with multiple controllers and must override CDC
>>> Ethernet.
>>>
>>> ** CID 501790:  Null pointer dereferences  (FORWARD_NULL)
>>> /cmd/bcb.c: 175 in __bcb_initialize()
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 501790:  Null pointer dereferences  (FORWARD_NULL)
>>> /cmd/bcb.c: 175 in __bcb_initialize()
>>> 169                     }
>>> 170             }
>>> 171
>>> 172             return CMD_RET_SUCCESS;
>>> 173
>>> 174     err_read_fail:
>>>>>>      CID 501790:  Null pointer dereferences  (FORWARD_NULL)
>>>>>>      Dereferencing null pointer "block".
>>> 175             printf("Error: %d %d:%s read failed (%d)\n",
>>> block->uclass_id,
>>> 176                    block->devnum, partition->name, ret);
>>> 177             __bcb_reset();
>>> 178             return CMD_RET_FAILURE;
>>> 179     }
>>> 180
>>
>> This probably deserves to be addressed. I don't know if Dmitrii is actively
>> watching the list so I'll study this in more detail and send a fix if appropriate.
>
> If blk_get_dev() returns NULL, we should write a message like "No such
> device" and return CMD_RET_FAILURE immediately.

Yes, thank you, I've submitted a fix:

https://lore.kernel.org/all/20240724-bcb-crash-v1-1-44caff15bce4@baylibre.com/


>
> Please, use log_err() for writing error messages. We don't need "Error:"
> at the beginning of error messages.

Is log_err() also the preferred way for commands? Since they are
interactive, it seems odd to have an "optional" message.

If it is, I'll convert the whole file in a separate, future patch.

>
> Best regards
>
> Heinrich
>
>>
>>>
>>> ** CID 501789:  Insecure data handling  (TAINTED_SCALAR)
>>> /lib/tpm_tcg2.c: 41 in tcg2_get_pcr_info()
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 501789:  Insecure data handling  (TAINTED_SCALAR)
>>> /lib/tpm_tcg2.c: 41 in tcg2_get_pcr_info()
>>> 35      memset(response, 0, sizeof(response));
>>> 36
>>> 37      ret = tpm2_get_pcr_info(dev, &pcrs);
>>> 38      if (ret)
>>> 39              return ret;
>>> 40
>>>>>>      CID 501789:  Insecure data handling  (TAINTED_SCALAR)
>>>>>>      Using tainted variable "pcrs.count" as a loop boundary.
>>> 41      for (i = 0; i < pcrs.count; i++) {
>>> 42              u32 hash_mask =
>>> tcg2_algorithm_to_mask(pcrs.selection[i].hash);
>>> 43
>>> 44              if (hash_mask) {
>>> 45                      *supported_pcr |= hash_mask;
>>> 46                      if (tpm2_is_active_pcr(&pcrs.selection[i]))
>>>
>>> ** CID 501788:  Memory - corruptions  (OVERRUN)
>>>
>>>
>>> ________________________________________________________________________________________________________
>>> *** CID 501788:  Memory - corruptions  (OVERRUN)
>>> /lib/tpm_tcg2.c: 658 in tcg2_measurement_term()
>>> 652                                bool error)
>>> 653     {
>>> 654             u32 event = error ? 0x1 : 0xffffffff;
>>> 655             int i;
>>> 656
>>> 657             for (i = 0; i < 8; ++i)
>>>>>>      CID 501788:  Memory - corruptions  (OVERRUN)
>>>>>>      Overrunning buffer pointed to by "(u8 const *)&event" of 4 bytes by
>>> passing it to a function which accesses it at byte offset 63.
>>> 658                     tcg2_measure_event(dev, elog, i, EV_SEPARATOR,
>>> sizeof(event),
>>> 659                                        (const u8 *)&event);
>>> 660
>>> 661             if (elog->log)
>>> 662                     unmap_physmem(elog->log, MAP_NOCACHE);
>>> 663     }
>>>
>>>
>>>
>>> ----- End forwarded message -----
>>>
>>> --
>>> Tom

  reply	other threads:[~2024-07-24  9:56 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23 14:18 Fwd: New Defects reported by Coverity Scan for Das U-Boot Tom Rini
2024-07-24  9:21 ` Mattijs Korpershoek
2024-07-24  9:45   ` Heinrich Schuchardt
2024-07-24  9:56     ` Mattijs Korpershoek [this message]
2024-07-24 10:06       ` Heinrich Schuchardt
2024-07-24 22:40         ` Tom Rini
2024-07-25  8:04           ` Mattijs Korpershoek
2024-07-25 17:16             ` Tom Rini
2024-07-24  9:53   ` Mattijs Korpershoek
  -- strict thread matches above, loose matches on Subject: below --
2026-04-06 19:12 Tom Rini
2026-03-09 21:23 Tom Rini
2026-03-09 22:05 ` Raphaël Gallais-Pou
2026-03-09 22:13   ` Tom Rini
2026-02-23 19:51 Tom Rini
2026-02-13 22:09 Tom Rini
2026-02-18 23:02 ` Chris Morgan
2026-02-20 16:11   ` Tom Rini
2026-02-20 16:23     ` Chris Morgan
2026-01-16 19:43 Tom Rini
2026-02-09 11:05 ` Guillaume La Roque
2026-02-20 16:11   ` Tom Rini
2026-01-06 20:36 Tom Rini
2026-01-05 23:58 Tom Rini
2026-01-06  9:37 ` Mattijs Korpershoek
2026-01-06 17:15   ` Tom Rini
2026-01-06 10:03 ` Heiko Schocher
2025-12-08 19:38 Tom Rini
2025-11-23 19:03 Tom Rini
2025-11-10 18:55 Tom Rini
2025-10-11 18:06 Tom Rini
2025-10-12 14:22 ` Mikhail Kshevetskiy
2025-10-12 19:07   ` Tom Rini
2025-11-01  6:32     ` Mikhail Kshevetskiy
2025-11-03 15:17       ` Tom Rini
2025-11-03 15:24         ` Michael Nazzareno Trimarchi
2025-08-06 18:35 Tom Rini
2025-08-07  9:17 ` Heiko Schocher
2025-08-08  3:37   ` Maniyam, Dinesh
2025-08-08  4:01     ` Heiko Schocher
2025-07-29 16:32 Tom Rini
2025-07-25 13:26 Tom Rini
2025-07-25 13:34 ` Michal Simek
2025-08-04  9:11 ` Alexander Dahl
2025-07-14 23:29 Tom Rini
2025-07-15 13:45 ` Rasmus Villemoes
2025-07-08 14:10 Tom Rini
2025-04-28 21:59 Tom Rini
2025-04-29 12:07 ` Jerome Forissier
2025-04-30 16:50 ` Marek Vasut
2025-04-30 17:01   ` Tom Rini
2025-04-30 18:23 ` Heinrich Schuchardt
2025-04-30 19:14   ` Tom Rini
2025-03-11  1:49 Tom Rini
2025-02-25  2:39 Tom Rini
2025-02-25  6:06 ` Heiko Schocher
2025-02-25 10:48   ` Quentin Schulz
2025-02-25 10:54     ` Heiko Schocher
2025-02-10 22:26 Tom Rini
2025-02-11  6:14 ` Heiko Schocher
2025-02-11 22:30   ` Tom Rini
2024-12-31 13:55 Tom Rini
2024-12-24 17:14 Tom Rini
2024-11-15 13:27 Tom Rini
2024-11-12  2:11 Tom Rini
2024-10-28  3:11 Tom Rini
2024-10-19 16:16 Tom Rini
2024-10-16  3:47 Tom Rini
2024-10-16  5:56 ` Tudor Ambarus
2024-10-07 17:15 Tom Rini
2024-04-22 21:48 Tom Rini
2024-01-29 23:55 Tom Rini
2024-01-30  8:14 ` Heinrich Schuchardt
     [not found] <20240127154018.GC785631@bill-the-cat>
2024-01-27 20:56 ` Heinrich Schuchardt
2024-01-28  8:51   ` Heinrich Schuchardt
2024-01-22 23:52 Tom Rini
2024-01-22 23:30 Tom Rini
2024-01-23  8:15 ` Hugo Cornelis
     [not found] <65a933ab652b3_da12cbd3e77f998728e5@prd-scan-dashboard-0.mail>
2024-01-19  8:47 ` Heinrich Schuchardt
2024-01-18 14:35 Tom Rini
2024-01-08 17:45 Tom Rini
2024-01-09  5:26 ` Sean Anderson
2024-01-09 22:18   ` Tom Rini
2023-08-21 21:09 Tom Rini
2023-08-24  9:27 ` Abdellatif El Khlifi
2023-08-28 16:09   ` Alvaro Fernando García
2023-08-28 16:11     ` Tom Rini
2023-10-20 11:57 ` Abdellatif El Khlifi
2023-10-25 14:57   ` Tom Rini
2023-10-25 15:12     ` Abdellatif El Khlifi
2023-10-25 15:15       ` Tom Rini
2023-10-31 14:21         ` Abdellatif El Khlifi
2023-05-08 20:20 Tom Rini
2023-05-15 21:59 ` Ehsan Mohandesi
2023-05-18 21:04 ` Sean Edmond
2023-02-14 14:26 Tom Rini
2022-11-21 19:43 Tom Rini
2022-11-09 15:40 Tom Rini
     [not found] <62df3a0cb9fd2_30ed5f2acd4da7b9a431758@prd-scan-dashboard-0.mail>
2022-07-26  4:22 ` Heinrich Schuchardt
     [not found] <611aaf735d268_21438d2b07184e399c79439@prd-scan-dashboard-0.mail>
2021-08-17  5:21 ` Heinrich Schuchardt
2021-08-17 15:17   ` Tom Rini
     [not found] <6082f7faa423_5762a2b148d4af9a86820@prd-scan-dashboard-0.mail>
2021-04-24  4:52 ` Heinrich Schuchardt
     [not found] <5ecd3c8249d1_d6f562acb748daf5820386@appnode-2.mail>
     [not found] ` <CA+M6bX=AmT+SyM0Snt2POLy0-vpD__6CD4j6ifqMqh63yYJBLA@mail.gmail.com>
     [not found]   ` <8ea1ca2f-2826-58f2-4b6b-ed5cfe977467@gmx.de>
     [not found]     ` <20200526184027.GJ12717@bill-the-cat>
2020-05-26 20:02       ` Heinrich Schuchardt
2020-05-26 20:10         ` Tom Rini
2020-05-26 20:36           ` Heinrich Schuchardt
2020-05-26 20:48             ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o76n5d1a.fsf@baylibre.com \
    --to=mkorpershoek@baylibre.com \
    --cc=dimorinny@google.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox