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] [day] [month] [year] [list]
Message-ID: <ffc12c5b-2481-ac02-5093-2f14d362ff26@collabora.com>
Date:   Mon, 8 Apr 2019 17:50:27 +0200
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Jett ✈ Rink <jettrink@...gle.com>,
        egranata@...omium.org
Cc:     Guenter Roeck <groeck@...gle.com>,
        Benson Leung <bleung@...omium.org>, gwendal@...omium.org,
        amstan@...omium.org, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] mfd: cros_ec: check for NULL transfer function

Hi Enrico,

Many thanks to send this upstream.

On 4/4/19 18:00, Jett ✈ Rink wrote:
> Reviewed-by: Jett Rink <jettrink@...omium.org>
> 
> On Wed, Apr 3, 2019 at 4:40 PM <egranata@...omium.org> wrote:
>>
>> From: Enrico Granata <egranata@...omium.org>
>>
>> As new transfer mechanisms are added to the EC codebase, they may
>> not support v2 of the EC protocol.
>>
>> If the v3 initial handshake transfer fails, the kernel will try
>> and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer
>> will be NULL, and the code will end up causing a kernel panic.
>>
>> Add a check for NULL before calling the transfer function, along
>> with a helpful comment explaining how one might end up in this
>> situation.
>>
>> Signed-off-by: Enrico Granata <egranata@...omium.org>
>> ---
>>  drivers/platform/chrome/cros_ec_proto.c | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
>> index 97a068dff192d..55691656a3c27 100644
>> --- a/drivers/platform/chrome/cros_ec_proto.c
>> +++ b/drivers/platform/chrome/cros_ec_proto.c
>> @@ -56,6 +56,16 @@ static int send_command(struct cros_ec_device *ec_dev,
>>         else
>>                 xfer_fxn = ec_dev->cmd_xfer;
>>
>> +       if (xfer_fxn == NULL) {
>> +               /* This error can happen if a communication error happened and

Like Guenter I personally don't like the networking-style multi-line comments.
We try to use the default kernel-style so if you don't mind I'll change this.


>> +                * the EC is trying to use protocol v2, on an underlying
>> +                * communication mechanism that does not support v2.
>> +                */
>> +               dev_err_once(ec_dev->dev,
>> +                       "missing EC transfer API, cannot send command\n");
>> +               return -EIO;
>> +       }
>> +
>>         ret = (*xfer_fxn)(ec_dev, msg);
>>         if (msg->result == EC_RES_IN_PROGRESS) {
>>                 int i;
>> --
>> 2.21.0.392.gf8f6787159e-goog
>>

I'll add the patch to the for-next branch in chrome-platform repository for
auto-builders to play with. If all goes well I'll queue the patch for
chrome-platform-5.2.

Thanks,
 Enric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ