netdev - RE: [RFC PATCH v3 4/8] CAIF Protocol Stack

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 16 Dec 2009 17:16:43 +0100
From:	Sjur Brændeland <sjur.brandeland@...ricsson.com>
To:	"stefano babic" <stefano.babic@...ic.homelinux.org>
Cc:	<netdev@...r.kernel.org>, <randy.dunlap@...cle.com>,
	"Kim Lilliestierna XX" <kim.xx.lilliestierna@...ricsson.com>,
	"Christian Bejram" <christian.bejram@...ricsson.com>,
	"Daniel Martensson" <daniel.martensson@...ricsson.com>
Subject: RE: [RFC PATCH v3  4/8] CAIF Protocol Stack

stefano babic wrote:
> sjur.brandeland@...ricsson.com wrote:
>> +struct cfcnfg *cfcnfg_create()
>> +{
>> +	struct cfcnfg *this;
>> +	struct cfctrl_rsp resp;
>> +	/* Initiate response functions */
>> +	resp.enum_rsp = cfctrl_enum_resp;
>> +	resp.linkerror_ind = cfctrl_resp_func;
>> +	resp.linkdestroy_rsp = cncfg_linkdestroy_rsp;
...
>> +	cfctrl_set_respfuncs(this->ctrl, &resp);
> 
> Is this correct ? resp is on the stack of the function and
> cfctrl_set_respfuncs sets only the pointer. After returning from this
> function, the memory used by resp could be reused again. Am I right ?
> 
Yes it is correct. But it sure looks odd, so I'll change this. 
But it's actually working because the content is copied by the statement 
this->res = *respfuncs; in cfctrl.c.

I'll change this code to something like this:
[snip]
	resp = cfctrl_get_respfuncs(this->ctrl);
	resp->enum_rsp = cfctrl_enum_resp;
	resp->linkerror_ind = cfctrl_resp_func;
	resp->linkdestroy_rsp = cncfg_linkdestroy_rsp;
	...
BR/Sjur

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html