U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Sean Anderson <seanga2@gmail.com>
Cc: u-boot@lists.denx.de,
	Francis Laniel <francis.laniel@amarulasolutions.com>,
	Michael Trimarchi <michael@amarulasolutions.com>,
	Dario Binacchi <dario.binacchi@amarulasolutions.com>
Subject: Re: Fwd: New Defects reported by Coverity Scan for Das U-Boot
Date: Tue, 9 Jan 2024 17:18:05 -0500	[thread overview]
Message-ID: <20240109221805.GC1610741@bill-the-cat> (raw)
In-Reply-To: <d873ed4d-25df-5ba0-67b3-c104d9da229d@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 11301 bytes --]

On Tue, Jan 09, 2024 at 12:26:13AM -0500, Sean Anderson wrote:
> Comments on NAND stuff only.
> 
> On 1/8/24 12:45, Tom Rini wrote:
> > ________________________________________________________________________________________________________
> > *** CID 477216:    (BAD_SHIFT)
> > /drivers/mtd/nand/raw/nand_base.c: 3921 in nand_flash_detect_onfi()
> > 3915
> > 3916            /*
> > 3917             * pages_per_block and blocks_per_lun may not be a
> > power-of-2 size
> > 3918             * (don't ask me who thought of this...). MTD assumes that these
> > 3919             * dimensions will be power-of-2, so just truncate the
> > remaining area.
> > 3920             */
> > > > >      CID 477216:    (BAD_SHIFT)
> > > > >      In expression "1 << generic_fls((__u32)(__le32)p->pages_per_block) - 1", shifting by a negative amount has undefined behavior.  The shift amount, "generic_fls((__u32)(__le32)p->pages_per_block) - 1", is -1.
> > 3921            mtd->erasesize = 1 <<
> > (fls(le32_to_cpu(p->pages_per_block)) - 1);
> > 3922            mtd->erasesize *= mtd->writesize;
> > 3923
> > 3924            mtd->oobsize = le16_to_cpu(p->spare_bytes_per_page);
> > 3925
> > 3926            /* See erasesize comment */
> > /drivers/mtd/nand/raw/nand_base.c: 3927 in nand_flash_detect_onfi()
> > 3921            mtd->erasesize = 1 <<
> > (fls(le32_to_cpu(p->pages_per_block)) - 1);
> > 3922            mtd->erasesize *= mtd->writesize;
> > 3923
> > 3924            mtd->oobsize = le16_to_cpu(p->spare_bytes_per_page);
> > 3925
> > 3926            /* See erasesize comment */
> > > > >      CID 477216:    (BAD_SHIFT)
> > > > >      In expression "1 << generic_fls((__u32)(__le32)p->blocks_per_lun) - 1", shifting by a negative amount has undefined behavior.  The shift amount, "generic_fls((__u32)(__le32)p->blocks_per_lun) - 1", is -1.
> > 3927            chip->chipsize = 1 << (fls(le32_to_cpu(p->blocks_per_lun)) - 1);
> > 3928            chip->chipsize *= (uint64_t)mtd->erasesize * p->lun_count;
> > 3929            chip->bits_per_cell = p->bits_per_cell;
> > 3930
> > 3931            if (onfi_feature(chip) & ONFI_FEATURE_16_BIT_BUS)
> > 3932                    chip->options |= NAND_BUSWIDTH_16;
> 
> Yeah, this looks like a bug.
> 
> > ** CID 477215:  Control flow issues  (MISSING_BREAK)
> > /drivers/mtd/nand/raw/nand_base.c: 4978 in nand_scan_tail()
> > 
> > 
> > ________________________________________________________________________________________________________
> > *** CID 477215:  Control flow issues  (MISSING_BREAK)
> > /drivers/mtd/nand/raw/nand_base.c: 4978 in nand_scan_tail()
> > 4972                            pr_warn("No ECC functions supplied;
> > hardware ECC not possible\n");
> > 4973                            BUG();
> > 4974                    }
> > 4975                    if (!ecc->read_page)
> > 4976                            ecc->read_page = nand_read_page_hwecc_oob_first;
> > 4977
> > > > >      CID 477215:  Control flow issues  (MISSING_BREAK)
> > > > >      The case for value "NAND_ECC_HW" is not terminated by a "break" statement.
> > 4978            case NAND_ECC_HW:
> > 4979                    /* Use standard hwecc read page function? */
> > 4980                    if (!ecc->read_page)
> > 4981                            ecc->read_page = nand_read_page_hwecc;
> > 4982                    if (!ecc->write_page)
> > 4983                            ecc->write_page = nand_write_page_hwecc;
> 
> I think we just need a fallthrough comment here.
> 
> > ** CID 477214:  Integer handling issues  (BAD_SHIFT)
> > /drivers/mtd/nand/raw/nand_base.c: 4397 in nand_detect()
> > 
> > 
> > ________________________________________________________________________________________________________
> > *** CID 477214:  Integer handling issues  (BAD_SHIFT)
> > /drivers/mtd/nand/raw/nand_base.c: 4397 in nand_detect()
> > 4391
> > 4392            nand_decode_bbm_options(mtd, chip);
> > 4393
> > 4394            /* Calculate the address shift from the page size */
> > 4395            chip->page_shift = ffs(mtd->writesize) - 1;
> > 4396            /* Convert chipsize to number of pages per chip -1 */
> > > > >      CID 477214:  Integer handling issues  (BAD_SHIFT)
> > > > >      In expression "chip->chipsize >> chip->page_shift", shifting by a negative amount has undefined behavior.  The shift amount, "chip->page_shift", is -1.
> > 4397            chip->pagemask = (chip->chipsize >> chip->page_shift) - 1;
> > 4398
> > 4399            chip->bbt_erase_shift = chip->phys_erase_shift =
> > 4400                    ffs(mtd->erasesize) - 1;
> > 4401            if (chip->chipsize & 0xffffffff)
> > 4402                    chip->chip_shift = ffs((unsigned)chip->chipsize) - 1;
> 
> Buggy, but only when writesize is 0 (which is a bigger bug in the nand chip).
> 
> > ** CID 477213:  Security best practices violations  (DC.WEAK_CRYPTO)
> > /test/dm/nand.c: 67 in dm_test_nand()
> > 
> > 
> > ________________________________________________________________________________________________________
> > *** CID 477213:  Security best practices violations  (DC.WEAK_CRYPTO)
> > /test/dm/nand.c: 67 in dm_test_nand()
> > 61      ops.ooblen = mtd->oobsize;
> > 62      ut_assertok(mtd_read_oob(mtd, mtd->erasesize, &ops));
> > 63      ut_asserteq(0, oob[mtd_to_nand(mtd)->badblockpos]);
> > 64
> > 65      /* Generate some data and write it */
> > 66      for (i = 0; i < size / sizeof(int); i++)
> > > > >      CID 477213:  Security best practices violations  (DC.WEAK_CRYPTO)
> > > > >      "rand" should not be used for security-related applications, because linear congruential algorithms are too easy to break.
> > 67              gold[i] = rand();
> > 68      ut_assertok(nand_write_skip_bad(mtd, off, &length, NULL, U64_MAX,
> > 69                                      (void *)gold, 0));
> > 70      ut_asserteq(size, length);
> > 71
> > 72      /* Verify */
> 
> Not a bug.
> 
> > ** CID 477211:  API usage errors  (ALLOC_FREE_MISMATCH)
> > /drivers/mtd/nand/raw/nand_bbt.c: 1133 in nand_scan_bbt()
> > 
> > 
> > ________________________________________________________________________________________________________
> > *** CID 477211:  API usage errors  (ALLOC_FREE_MISMATCH)
> > /drivers/mtd/nand/raw/nand_bbt.c: 1133 in nand_scan_bbt()
> > 1127
> > 1128            /* Prevent the bbt regions from erasing / writing */
> > 1129            mark_bbt_region(mtd, td);
> > 1130            if (md)
> > 1131                    mark_bbt_region(mtd, md);
> > 1132
> > > > >      CID 477211:  API usage errors  (ALLOC_FREE_MISMATCH)
> > > > >      Calling "vfree" frees "buf" using "vfree" but it should have been freed using "kfree". [Note: The source code implementation of the function has been overridden by a builtin model.]
> > 1133            vfree(buf);
> > 1134            return 0;
> > 1135
> > 1136     err:
> > 1137            kfree(this->bbt);
> > 1138            this->bbt = NULL;
> 
> Not a bug, since these both call free().
> 
> > ** CID 477210:  Security best practices violations  (DC.WEAK_CRYPTO)
> > /drivers/mtd/nand/raw/sand_nand.c: 199 in sand_nand_read()
> > 
> > 
> > ________________________________________________________________________________________________________
> > *** CID 477210:  Security best practices violations  (DC.WEAK_CRYPTO)
> > /drivers/mtd/nand/raw/sand_nand.c: 199 in sand_nand_read()
> > 193             chip->tmp_dirty = true;
> > 194             for (i = 0; i < chip->err_steps; i++) {
> > 195                     u32 bit_errors = chip->err_count;
> > 196                     unsigned int j = chip->err_step_bits + chip->ecc_bits;
> > 197
> > 198                     while (bit_errors) {
> > > > >      CID 477210:  Security best practices violations  (DC.WEAK_CRYPTO)
> > > > >      "rand" should not be used for security-related applications, because linear congruential algorithms are too easy to break.
> > 199                             unsigned int u = rand();
> > 200                             float quot = 1ULL << 32;
> > 201
> > 202                             do {
> > 203                                     quot *= j - bit_errors;
> > 204                                     quot /= j;
> 
> Not a bug.
> 
> > ** CID 477207:  Control flow issues  (MISSING_BREAK)
> > /drivers/mtd/nand/raw/nand_base.c: 4969 in nand_scan_tail()
> > 
> > 
> > ________________________________________________________________________________________________________
> > *** CID 477207:  Control flow issues  (MISSING_BREAK)
> > /drivers/mtd/nand/raw/nand_base.c: 4969 in nand_scan_tail()
> > 4963            /*
> > 4964             * Check ECC mode, default to software if
> > 3byte/512byte hardware ECC is
> > 4965             * selected and we have 256 byte pagesize fallback to
> > software ECC
> > 4966             */
> > 4967
> > 4968            switch (ecc->mode) {
> > > > >      CID 477207:  Control flow issues  (MISSING_BREAK)
> > > > >      The case for value "NAND_ECC_HW_OOB_FIRST" is not terminated by a "break" statement.
> > 4969            case NAND_ECC_HW_OOB_FIRST:
> > 4970                    /* Similar to NAND_ECC_HW, but a separate
> > read_page handle */
> > 4971                    if (!ecc->calculate || !ecc->correct || !ecc->hwctl) {
> > 4972                            pr_warn("No ECC functions supplied;
> > hardware ECC not possible\n");
> > 4973                            BUG();
> > 4974                    }
> 
> need a fallthrough comment
> 
> > ** CID 477205:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
> > /cmd/mtd.c: 88 in mtd_dump_device_buf()
> > 
> > 
> > ________________________________________________________________________________________________________
> > *** CID 477205:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
> > /cmd/mtd.c: 88 in mtd_dump_device_buf()
> > 82                      printf("\nDump %d data bytes from 0x%08llx:\n",
> > 83                             mtd->writesize, start_off + data_off);
> > 84                      mtd_dump_buf(&buf[data_off],
> > 85                                   mtd->writesize, start_off + data_off);
> > 86
> > 87                      if (woob) {
> > > > >      CID 477205:  Integer handling issues  (OVERFLOW_BEFORE_WIDEN)
> > > > >      Potentially overflowing expression "page * mtd->oobsize" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "u64" (64 bits, unsigned).
> > 88                              u64 oob_off = page * mtd->oobsize;
> > 89
> > 90                              printf("Dump %d OOB bytes from page at
> > 0x%08llx:\n",
> > 91                                     mtd->oobsize, start_off + data_off);
> > 92                              mtd_dump_buf(&buf[len + oob_off],
> > 93                                           mtd->oobsize, 0);
> 
> In the Linux MTD list [1], the largest this can be is 0xe0000000 for MT29F512G08CUCAB. That's worryingly
> close to overflow, so I'd say this is a bug.

Thanks, I've updated the not a bug ones in the dashboard.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2024-01-09 22:18 UTC|newest]

Thread overview: 120+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08 17:45 Fwd: New Defects reported by Coverity Scan for Das U-Boot Tom Rini
2024-01-09  5:26 ` Sean Anderson
2024-01-09 22:18   ` Tom Rini [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-08-10 23:14 Tom Rini
2026-07-29 17:07 Tom Rini
2026-07-07 18:58 Tom Rini
2026-06-22 22:43 Tom Rini
2026-06-26 18:28 ` Quentin Schulz
2026-06-26 18:32   ` Dario Binacchi
2026-06-26 21:53   ` Tom Rini
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-07-23 14:18 Tom Rini
2024-07-24  9:21 ` Mattijs Korpershoek
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
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
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=20240109221805.GC1610741@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=dario.binacchi@amarulasolutions.com \
    --cc=francis.laniel@amarulasolutions.com \
    --cc=michael@amarulasolutions.com \
    --cc=seanga2@gmail.com \
    --cc=u-boot@lists.denx.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