[PATCH 3.16 117/305] UBI: do propagate positive error codes up

From: Ben Hutchings
Date: Sun Aug 14 2016 - 07:29:42 EST


3.16.37-rc1 review patch. If anyone has any objections, please let me know.

------------------

From: Artem Bityutskiy <artem.bityutskiy@xxxxxxxxxxxxxxx>

commit 0e707ae79ba357d60b8a36025ec8968e5020d827 upstream.

UBI uses positive function return codes internally, and should not propagate
them up, except in the place this path fixes. Here is the original bug report
from Dan Carpenter:

The problem is really in ubi_eba_read_leb().

drivers/mtd/ubi/eba.c
412 err = ubi_io_read_vid_hdr(ubi, pnum, vid_hdr, 1);
413 if (err && err != UBI_IO_BITFLIPS) {
414 if (err > 0) {
415 /*
416 * The header is either absent or corrupted.
417 * The former case means there is a bug -
418 * switch to read-only mode just in case.
419 * The latter case means a real corruption - we
420 * may try to recover data. FIXME: but this is
421 * not implemented.
422 */
423 if (err == UBI_IO_BAD_HDR_EBADMSG ||
424 err == UBI_IO_BAD_HDR) {
425 ubi_warn("corrupted VID header at PEB %d, LEB %d:%d",
426 pnum, vol_id, lnum);
427 err = -EBADMSG;
428 } else
429 ubi_ro_mode(ubi);

On this path we return UBI_IO_FF and UBI_IO_FF_BITFLIPS and it
eventually gets passed to ERR_PTR(). We probably dereference the bad
pointer and oops. At that point we've gone read only so it was already
a bad situation...

430 }
431 goto out_free;
432 } else if (err == UBI_IO_BITFLIPS)
433 scrub = 1;
434

Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@xxxxxxxxxxxxxxx>
Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
---
drivers/mtd/ubi/eba.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/mtd/ubi/eba.c
+++ b/drivers/mtd/ubi/eba.c
@@ -426,6 +426,7 @@ retry:
pnum, vol_id, lnum);
err = -EBADMSG;
} else
+ err = -EINVAL;
ubi_ro_mode(ubi);
}
goto out_free;