Re: [PATCH RESEND] power: supply: avoid nullptr deref in __power_supply_is_system_supplied

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hi Sebastian,

On Sun, Sep 11, 2022 at 02:33:46PM +0200, Sebastian Reichel wrote:
> > -	if (psy->desc->type != POWER_SUPPLY_TYPE_BATTERY)
> > +	if (psy->desc->type != POWER_SUPPLY_TYPE_BATTERY && psy->desc->get_property)
> >  		if (!psy->desc->get_property(psy, POWER_SUPPLY_PROP_ONLINE,
> >  					&ret))
> >  			return ret.intval;
> 
> Thanks, queued into power-supply's fixes branch. But I'm curioous
> how you triggered this. Which power-supply driver does not add
> a get_property function?

AFAIK, I'm just using the normal ACPI one. Really nothing fancy.
Thinkpad X1 Extreme Gen 4.

Maybe get_property was being set and unset during some kind of
initialization/deinitialization that was happening in response to some
other event? Not sure, except that I managed to trigger it twice before
patching my kernel so my laptop would keep working.

My machine went through three changes I know about between the threshold
of "not crashing" and "crashing":
- Upgraded to 5.19 and then 6.0-rc1.
- I used my laptop on batteries for a prolonged period of time for the
  first time in a while.
- I updated KDE, whose power management UI elements may or may not make
  frequent calls to this subsystem to update some visual representation.

I don't have any data to back up this claim at all, but something that
at least _sounds_ plausible is that an updated KDE thing was hammering
on this read() method, while a decreasing battery state caused some
aspect of the subsystem to reinitialize the power management object,
making ->get_property() temporarily NULL. But just a guess!

Jason