From: Mattijs Korpershoek <mkorpershoek@baylibre.com>
To: Tom Rini <trini@konsulko.com>,
u-boot@lists.denx.de,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
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:21:43 +0200 [thread overview]
Message-ID: <87ttgf5emw.fsf@baylibre.com> (raw)
In-Reply-To: <20240723141844.GF989285@bill-the-cat>
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.
> 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.
>
> ** 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
next prev parent reply other threads:[~2024-07-24 9:21 UTC|newest]
Thread overview: 99+ 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 [this message]
2024-07-24 9:45 ` Heinrich Schuchardt
2024-07-24 9:56 ` Mattijs Korpershoek
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-05-11 22:35 Tom Rini
2026-05-08 23:42 Tom Rini
2026-05-14 15:39 ` Lucien.Jheng
2026-04-28 14:04 Tom Rini
2026-04-29 6:31 ` Michal Simek
2026-05-01 22:51 ` Raymond Mao
2026-05-12 8:44 ` Christian Pötzsch
2026-05-12 18:38 ` Tom Rini
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
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=87ttgf5emw.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.