Fix undefined behavior in spa_sync_props()
commitee7b71dbc919439b1db6352bcd95f121127b42dd
authorRichard Yao <richard.yao@alumni.stonybrook.edu>
Fri, 12 May 2023 21:10:14 +0000 (12 17:10 -0400)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Mon, 15 May 2023 17:29:05 +0000 (15 10:29 -0700)
treec2585e6db8cbca29d11f1c78ab5ed6220d9f5244
parentc87798d8ff6a63158e80acbbce8b034518a1656e
Fix undefined behavior in spa_sync_props()

8eae2d214cfa53862833eeeda9a5c1e9d5ded47d caused Coverity to begin
complaining about "Improper use of negative value" in two places in
spa_sync_props() because Coverity correctly inferred from `prop ==
ZPOOL_PROP_INVAL` that prop could be -1 while both zpool_prop_to_name()
and zpool_prop_get_type() use it an array index, which is undefined
behavior.

Assuming that the system does not panic from an attempt to read invalid
memory, the case statement for ZPOOL_PROP_INVAL will ensure that only
user properties will reach this code when prop is ZPOOL_PROP_INVAL, such
that execution will continue safely. However, if we are unlucky enough
to read invalid memory, then the system will panic.

This issue predates the patch that caused coverity to begin complaining.
Thankfully, our userland tools do not pass nonsense to us, so this bug
should not be triggered unless a future userland tool attempts to set a
property that we do not understand.

Reported-by: Coverity (CID-1561129)
Reported-by: Coverity (CID-1561130)
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: George Amanakis <gamanakis@gmail.com>
Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Closes #14860
module/zfs/spa.c