Coverity: _iwl_dbgfs_fw_dbg_domain_write(): Insecure data handling

Coverity: _iwl_dbgfs_fw_dbg_domain_write(): Insecure data handling

[coverity-bot]

Hello!

This is an experimental automated report about issues detected by Coverity
from a scan of next-20191031 as part of the linux-next weekly scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan

You're getting this email because you were associated with the identified
lines of code (noted below) that were touched by recent commits:

068893b7a28f ("iwlwifi: dbg_ini: support domain changing via debugfs")

Coverity reported the following:

*** CID 1487394:  Insecure data handling  (TAINTED_SCALAR)
/drivers/net/wireless/intel/iwlwifi/fw/debugfs.c: 355 in _iwl_dbgfs_fw_dbg_domain_write()
349     					    size_t size, char *buf)
350     {
351     	return scnprintf(buf, size, "0x%08x\n",
352     			 fwrt->trans->dbg.domains_bitmap);
353     }
354
vvv     CID 1487394:  Insecure data handling  (TAINTED_SCALAR)
vvv     Passing tainted variable "buf" to a tainted sink.
355     FWRT_DEBUGFS_READ_WRITE_FILE_OPS(fw_dbg_domain, 20);
356
357     void iwl_fwrt_dbgfs_register(struct iwl_fw_runtime *fwrt,
358     			    struct dentry *dbgfs_dir)
359     {
360     	INIT_DELAYED_WORK(&fwrt->timestamp.wk, iwl_fw_timestamp_marker_wk);
361     	FWRT_DEBUGFS_ADD_FILE(timestamp_marker, dbgfs_dir, 0200);
362     	FWRT_DEBUGFS_ADD_FILE(send_hcmd, dbgfs_dir, 0200);
363     	FWRT_DEBUGFS_ADD_FILE(fw_dbg_domain, dbgfs_dir, 0600);

If this is a false positive, please let us know so we can mark it as
such, or teach the Coverity rules to be smarter. If not, please make
sure fixes get into linux-next. :) For patches fixing this, please
include these lines (but double-check the "Fixes" first):

Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
Addresses-Coverity-ID: 1487394 ("Insecure data handling")
Fixes: 068893b7a28f ("iwlwifi: dbg_ini: support domain changing via debugfs")


Thanks for your attention!

-- 
Coverity-bot

Re: Coverity: _iwl_dbgfs_fw_dbg_domain_write(): Insecure data handling

[Luciano Coelho]

On Mon, 2019-11-04 at 09:42 -0800, coverity-bot wrote:
> Hello!
> 
> This is an experimental automated report about issues detected by Coverity
> from a scan of next-20191031 as part of the linux-next weekly scan project:
> https://scan.coverity.com/projects/linux-next-weekly-scan
> 
> You're getting this email because you were associated with the identified
> lines of code (noted below) that were touched by recent commits:
> 
> 068893b7a28f ("iwlwifi: dbg_ini: support domain changing via debugfs")
> 
> Coverity reported the following:
> 
> *** CID 1487394:  Insecure data handling  (TAINTED_SCALAR)
> /drivers/net/wireless/intel/iwlwifi/fw/debugfs.c: 355 in _iwl_dbgfs_fw_dbg_domain_write()
> 349     					    size_t size, char *buf)
> 350     {
> 351     	return scnprintf(buf, size, "0x%08x\n",
> 352     			 fwrt->trans->dbg.domains_bitmap);
> 353     }
> 354
> vvv     CID 1487394:  Insecure data handling  (TAINTED_SCALAR)
> vvv     Passing tainted variable "buf" to a tainted sink.
> 355     FWRT_DEBUGFS_READ_WRITE_FILE_OPS(fw_dbg_domain, 20);
> 356
> 357     void iwl_fwrt_dbgfs_register(struct iwl_fw_runtime *fwrt,
> 358     			    struct dentry *dbgfs_dir)
> 359     {
> 360     	INIT_DELAYED_WORK(&fwrt->timestamp.wk, iwl_fw_timestamp_marker_wk);
> 361     	FWRT_DEBUGFS_ADD_FILE(timestamp_marker, dbgfs_dir, 0200);
> 362     	FWRT_DEBUGFS_ADD_FILE(send_hcmd, dbgfs_dir, 0200);
> 363     	FWRT_DEBUGFS_ADD_FILE(fw_dbg_domain, dbgfs_dir, 0600);
> 
> If this is a false positive, please let us know so we can mark it as
> such, or teach the Coverity rules to be smarter. If not, please make
> sure fixes get into linux-next. :) For patches fixing this, please
> include these lines (but double-check the "Fixes" first):
> 
> Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
> Addresses-Coverity-ID: 1487394 ("Insecure data handling")
> Fixes: 068893b7a28f ("iwlwifi: dbg_ini: support domain changing via debugfs")
> 
> 
> Thanks for your attention!

We have removed the "write" part of this debugfs entry, so this is not
applicable anymore.

Thanks for reporting!

--
Cheers,
Luca.