public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [BUG 6.4-rc3] BUG: kernel NULL pointer dereference in __dev_fwnode
       [not found] <20230524131200.0f6fb318@rorschach.local.home>
@ 2023-05-24 18:28 ` Linus Torvalds
  2023-05-25 16:42   ` Sebastian Reichel
  0 siblings, 1 reply; 3+ messages in thread
From: Linus Torvalds @ 2023-05-24 18:28 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: LKML, Masami Hiramatsu, Sebastian Reichel, Linus Walleij,
	Matti Vaittinen, linux-pm

On Wed, May 24, 2023 at 10:12 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I started adding fixes to my urgent branch rebased on top of v6.4-rc3
> and ran my tests. Unfortunately they crashed on unrelated code.
>
> Here's the dump:
>
>  BUG: kernel NULL pointer dereference, address: 00000000000003e8
>  RIP: 0010:__dev_fwnode+0x9/0x2a
>  Code: ff 85 c0 78 16 48 8b 3c 24 89 c6 59 e9 e0 f7 ff ff b8 ea ff ff ff c3 cc cc cc cc 5a c3 cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 <48> 8b 87 e8 03 00 00 48
>  83 c0 18 c3 cc cc cc cc 48

That disassembles to

    endbr64
    nopl   0x0(%rax,%rax,1)
    mov    0x3e8(%rdi),%rax
    add    $0x18,%rax
    ret

which looks like it must be the

    return dev->fwnode;

with a NULL 'dev'. Which makes sense for __dev_fwnode with CONFIG_OF
not enabled.

Except I have no idea what that odd 'add $0x18" is all about. Strange.

Anyway, the caller seems to be this code in power_supply_get_battery_info():

        if (psy->of_node) {
            .. presumably not this ..
        } else {
                err = fwnode_property_get_reference_args(
                                        dev_fwnode(psy->dev.parent),
                                        "monitored-battery", NULL, 0, 0, &args);
                ...

so I suspect we have psy->dev.parent being NULL.

>  I ran a bisect and it found it to be this commit:
>
> 27a2195efa8d2 ("power: supply: core: auto-exposure of simple-battery data")
>
> I checked out that commit and tested it, and it crashed. I then
> reverted that commit, and the crash goes away.

At a guess, it's

 (a) the new code to expose battery info at registration time:

+       /*
+        * Expose constant battery info, if it is available. While there are
+        * some chargers accessing constant battery data, we only want to
+        * expose battery data to userspace for battery devices.
+        */
+       if (desc->type == POWER_SUPPLY_TYPE_BATTERY) {
+               rc = power_supply_get_battery_info(psy, &psy->battery_info);
+               if (rc && rc != -ENODEV && rc != -ENOENT)
+                       goto check_supplies_failed;
+       }

interacting with

 (b) the test_power_init() that does that

                test_power_supplies[i] = power_supply_register(NULL,
                                                &test_power_desc[i],
                                                &test_power_configs[i]);

which passes in NULL for the "parent" pointer.

So it looks like a dodgy test that was a bit lazy. But maybe a NULL
parent is supposed to work.

                Linus

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [BUG 6.4-rc3] BUG: kernel NULL pointer dereference in __dev_fwnode
  2023-05-24 18:28 ` [BUG 6.4-rc3] BUG: kernel NULL pointer dereference in __dev_fwnode Linus Torvalds
@ 2023-05-25 16:42   ` Sebastian Reichel
  2023-05-26  2:08     ` Steven Rostedt
  0 siblings, 1 reply; 3+ messages in thread
From: Sebastian Reichel @ 2023-05-25 16:42 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, LKML, Masami Hiramatsu, Linus Walleij,
	Matti Vaittinen, linux-pm

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

Hi,

On Wed, May 24, 2023 at 11:28:41AM -0700, Linus Torvalds wrote:
> On Wed, May 24, 2023 at 10:12 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > I started adding fixes to my urgent branch rebased on top of v6.4-rc3
> > and ran my tests. Unfortunately they crashed on unrelated code.
> >
> > Here's the dump:
> >
> >  BUG: kernel NULL pointer dereference, address: 00000000000003e8
> >  RIP: 0010:__dev_fwnode+0x9/0x2a
> >  Code: ff 85 c0 78 16 48 8b 3c 24 89 c6 59 e9 e0 f7 ff ff b8 ea ff ff ff c3 cc cc cc cc 5a c3 cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 <48> 8b 87 e8 03 00 00 48
> >  83 c0 18 c3 cc cc cc cc 48
> 
> That disassembles to
> 
>     endbr64
>     nopl   0x0(%rax,%rax,1)
>     mov    0x3e8(%rdi),%rax
>     add    $0x18,%rax
>     ret
> 
> which looks like it must be the
> 
>     return dev->fwnode;
> 
> with a NULL 'dev'. Which makes sense for __dev_fwnode with CONFIG_OF
> not enabled.
> 
> Except I have no idea what that odd 'add $0x18" is all about. Strange.
> 
> Anyway, the caller seems to be this code in power_supply_get_battery_info():
> 
>         if (psy->of_node) {
>             .. presumably not this ..
>         } else {
>                 err = fwnode_property_get_reference_args(
>                                         dev_fwnode(psy->dev.parent),
>                                         "monitored-battery", NULL, 0, 0, &args);
>                 ...
> 
> so I suspect we have psy->dev.parent being NULL.
> 
> >  I ran a bisect and it found it to be this commit:
> >
> > 27a2195efa8d2 ("power: supply: core: auto-exposure of simple-battery data")
> >
> > I checked out that commit and tested it, and it crashed. I then
> > reverted that commit, and the crash goes away.
> 
> At a guess, it's
> 
>  (a) the new code to expose battery info at registration time:
> 
> +       /*
> +        * Expose constant battery info, if it is available. While there are
> +        * some chargers accessing constant battery data, we only want to
> +        * expose battery data to userspace for battery devices.
> +        */
> +       if (desc->type == POWER_SUPPLY_TYPE_BATTERY) {
> +               rc = power_supply_get_battery_info(psy, &psy->battery_info);
> +               if (rc && rc != -ENODEV && rc != -ENOENT)
> +                       goto check_supplies_failed;
> +       }
> 
> interacting with
> 
>  (b) the test_power_init() that does that
> 
>                 test_power_supplies[i] = power_supply_register(NULL,
>                                                 &test_power_desc[i],
>                                                 &test_power_configs[i]);
> 
> which passes in NULL for the "parent" pointer.
> 
> So it looks like a dodgy test that was a bit lazy. But maybe a NULL
> parent is supposed to work.
> 
>                 Linus

I have a fix for that in my fixes branch, that I planned to send
this week:

https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git/commit/?h=fixes&id=44c524b642996148a8e94f1a1b8751076edcf577

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [BUG 6.4-rc3] BUG: kernel NULL pointer dereference in __dev_fwnode
  2023-05-25 16:42   ` Sebastian Reichel
@ 2023-05-26  2:08     ` Steven Rostedt
  0 siblings, 0 replies; 3+ messages in thread
From: Steven Rostedt @ 2023-05-26  2:08 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Linus Torvalds, LKML, Masami Hiramatsu, Linus Walleij,
	Matti Vaittinen, linux-pm

On Thu, 25 May 2023 18:42:48 +0200
Sebastian Reichel <sre@kernel.org> wrote:

> I have a fix for that in my fixes branch, that I planned to send
> this week:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git/commit/?h=fixes&id=44c524b642996148a8e94f1a1b8751076edcf577

This appears to fix the bug I reported.

Tested-by: Steven Rostedt (Google) <rostedt@goodmis.org>

-- Steve

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-05-26  2:08 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20230524131200.0f6fb318@rorschach.local.home>
2023-05-24 18:28 ` [BUG 6.4-rc3] BUG: kernel NULL pointer dereference in __dev_fwnode Linus Torvalds
2023-05-25 16:42   ` Sebastian Reichel
2023-05-26  2:08     ` Steven Rostedt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox