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] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM6PR11MB4657E75C585584960CFBD09C9BA8A@DM6PR11MB4657.namprd11.prod.outlook.com>
Date: Wed, 8 Nov 2023 12:08:12 +0000
From: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
To: "Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "vadim.fedorenko@...ux.dev" <vadim.fedorenko@...ux.dev>,
	"jiri@...nulli.us" <jiri@...nulli.us>, "Michalik, Michal"
	<michal.michalik@...el.com>, "Olech, Milena" <milena.olech@...el.com>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "kuba@...nel.org" <kuba@...nel.org>
Subject: RE: [PATCH net 1/3] dpll: fix pin dump crash after module unbind

>From: Kitszel, Przemyslaw <przemyslaw.kitszel@...el.com>
>Sent: Wednesday, November 8, 2023 12:36 PM
>
>On 11/8/23 11:32, Arkadiusz Kubalewski wrote:
>> Disallow dump of unregistered parent pins, it is possible when parent
>> pin and dpll device registerer kernel module instance unbinds, and
>> other kernel module instances of the same dpll device have pins
>> registered with the parent pin. The user can invoke a pin-dump but as
>> the parent was unregistered, thus shall not be accessed by the
>> userspace, prevent that by checking if parent pin is still registered.
>>
>> Fixes: 9d71b54b65b1 ("dpll: netlink: Add DPLL framework base functions")
>> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>
>> ---
>>   drivers/dpll/dpll_netlink.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
>> index a6dc3997bf5c..93fc6c4b8a78 100644
>> --- a/drivers/dpll/dpll_netlink.c
>> +++ b/drivers/dpll/dpll_netlink.c
>> @@ -328,6 +328,13 @@ dpll_msg_add_pin_parents(struct sk_buff *msg, struct
>dpll_pin *pin,
>>   		void *parent_priv;
>>
>>   		ppin = ref->pin;
>> +		/*
>> +		 * dump parent only if it is registered, thus prevent crash on
>> +		 * pin dump called when driver which registered the pin unbinds
>> +		 * and different instance registered pin on that parent pin
>> +		 */
>> +		if (!xa_get_mark(&dpll_pin_xa, ppin->id, DPLL_REGISTERED))
>> +			continue;
>
>What if unregister/unbind would happen right [here]?
>[here]

There is a "global" mutex lock which guards the pin/dpll registration and all
netlink requests. For netlink requests in this case it is acquired in the
dpll_pin_pre_doit(..), while all the dpll subsystem interaction from kernel
modules are guarded in dpll_core.c api functions with the same lock.

So after all this use case is protected, just "higher" in the stack.

Thank you!
Arkadiusz

>
>>   		parent_priv = dpll_pin_on_dpll_priv(dpll_ref->dpll, ppin);
>>   		ret = ops->state_on_pin_get(pin,
>>   					    dpll_pin_on_pin_priv(ppin, pin),

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ