linux-kernel - Re: BUG: hid-sensor-ids code includes binary data in device name

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: <317ce138f63b9317ac7be1949a68db5117c19b92.camel@linux.intel.com>
Date:   Fri, 10 Mar 2023 01:51:41 -0800
From:   srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>
To:     todd.e.brandt@...ux.intel.com, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, Even Xu <even.xu@...el.com>
Cc:     p.jungkamp@....net, Jonathan.Cameron@...wei.com, jkosina@...e.cz,
        todd.e.brandt@...el.com
Subject: Re: BUG: hid-sensor-ids code includes binary data in device name

+Even

On Thu, 2023-03-09 at 15:33 -0800, Todd Brandt wrote:
> Hi all, I've run into an issue in 6.3.0-rc1 that causes problems with
> ftrace and I've bisected it to this commit:
> 
> commit 98c062e8245199fa9121141a0bf1035dc45ae90e (HEAD,
> refs/bisect/bad)
> Author: Philipp Jungkamp p.jungkamp@....net
> Date:   Fri Nov 25 00:38:38 2022 +0100
> 
>     HID: hid-sensor-custom: Allow more custom iio sensors
> 
>     The known LUID table for established/known custom HID sensors was
>     limited to sensors with "INTEL" as manufacturer. But some vendors
> such
>     as Lenovo also include fairly standard iio sensors (e.g. ambient
> light)
>     in their custom sensors.
> 
>     Expand the known custom sensors table by a tag used for the
> platform
>     device name and match sensors based on the LUID as well as
> optionally
>     on model and manufacturer properties.
> 
>     Signed-off-by: Philipp Jungkamp p.jungkamp@....net
>     Reviewed-by: Jonathan Cameron Jonathan.Cameron@...wei.com
>     Acked-by: Srinivas Pandruvada srinivas.pandruvada@...ux.intel.com
>     Signed-off-by: Jiri Kosina jkosina@...e.cz
> 
> You're using raw data as part of the devname in the "real_usage"
> string, but it includes chars other than ASCII, and those chars end
> up being printed out in the ftrace log which is meant to be ASCII
> only.
> 
> -       /* HID-SENSOR-INT-REAL_USAGE_ID */
> -       dev_name = kasprintf(GFP_KERNEL, "HID-SENSOR-INT-%s",
> real_usage);
> +       /* HID-SENSOR-TAG-REAL_USAGE_ID */
> +       dev_name = kasprintf(GFP_KERNEL, "HID-SENSOR-%s-%s",
> +                            match->tag, real_usage);
> 
> My sleepgraph tool started to crash because it read these lines from
> ftrace:
> 
> device_pm_callback_start: platform HID-SENSOR-INT-020b?.39.auto,
> parent: 001F:8087:0AC2.0003, [suspend]
> device_pm_callback_end: platform HID-SENSOR-INT-020b?.39.auto, err=0
> 

Here tag is:
.tag = "INT",
.luid = "020B000000000000",


The LUID is still a string. Probably too long for a dev_name.

Even,

Please check.

Thanks.
Srinivas


> The "HID-SENSOR-INT-020b?.39.auto" string includes a binary char that
> kills
> python3 code that loops through an ascii file as such:
> 
>   File "/usr/bin/sleepgraph", line 5579, in executeSuspend
>     for line in fp:
>   File "/usr/lib/python3.10/codecs.py", line 322, in decode
>     (result, consumed) = self._buffer_decode(data, self.errors,
> final)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position
> 1568: invalid start byte
> 
> I've updated sleepgraph to handle random non-ascii chars, but other
> tools
> may suffer the same fate. Can you rewrite this to ensure that no
> binary
> chars make it into the devname?
>