linux-kernel - Re: [PATCH v2] nvmem: u-boot-env: improve error checking

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: <20240130232536.1194952-1-nicholas.spooner@seagate.com>
Date: Tue, 30 Jan 2024 16:25:36 -0700
From: Nick Spooner <nicholas.spooner@...gate.com>
To: rafal@...ecki.pl
Cc: dan.carpenter@...aro.org,
	evan.burgess@...gate.com,
	kernel-janitors@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	nicholas.spooner@...gate.com,
	srinivas.kandagatla@...aro.org
Subject: Re: [PATCH v2] nvmem: u-boot-env: improve error checking

Hi Rafał,

> I'd appreciate description why do we need this change other than
> addressing some Coverity report.

I've been looking at Coverity for bugs to fix when it was brought up on
the kernel-janitors mailing list as a way to gain experience with the
kernel tree. This issue stood out to me specifically because all other
instances of nvmem_add_one_cell (in core.c, onie-tlv.c, and sl28vpd.c) are
checked for errors. I figured I'd add a check for the one in u-boot-env.c
so that they're all covered, but I understand if this is a case where we
don't want to try to fix something that isn't necessarily broken.

> Should a single nvmem_add_one_cell() failure result in not registering
> NVMEM device at all? Why?

I see that the only place where the return value of u_boot_env_add_cells
gets checked is in the same file on line 192, where u_boot_env_parse sets
err. The only time err won't be 0 is if info.name causes u_boot_env_add_cells
to return -ENOMEM. So is that the only case where err should be set, or
should err report if any cells failed to register? I followed the logic
backwards and found that .probe is set to whatever u_boot_env_probe return,
so I'm guessing it's a matter of what .probe should include or not. Let me
know if my logic is incorrect anywhere.

Thanks,
Nick Spooner