Good eye for spotting the memory corruption bug! This is a bug fix, so the fix should go in a separate patch and not merged with a code cleanup patch. Ordinary users can trigger this so it's a security bug and separating it out is extra important.
The checking in spk_set_num_var() is not sufficient as well. If we use E_INC then we can hit an integer overflow bug: drivers/staging/speakup/varhandlers.c 198 if (how == E_SET) 199 val = input; 200 else 201 val = var_data->u.n.value; 202 if (how == E_INC) 203 val += input; "input" comes from the user. This addition can overflow so that input is a very high number and now "val" is a low enough number. 204 else if (how == E_DEC) 205 val -= input; 206 if (val < var_data->u.n.low || val > var_data->u.n.high) 207 return -ERANGE; "val" is valid, but "input" is not valid. We use "input" in the caller function as the index to an array. 208 } I guess that's simple enough to fix but why is the caller using "input" instead of "val"? regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
