[<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