<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/platform, branch linux-6.0.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-6.0.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-6.0.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-12-31T12:26:47+00:00</updated>
<entry>
<title>regulator: core: Use different devices for resource allocation and DT lookup</title>
<updated>2022-12-31T12:26:47+00:00</updated>
<author>
<name>ChiYuan Huang</name>
<email>cy_huang@richtek.com</email>
</author>
<published>2022-12-06T07:22:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cb29811d989bcb7ea81ca111c4b13878b344e086'/>
<id>urn:sha1:cb29811d989bcb7ea81ca111c4b13878b344e086</id>
<content type='text'>
[ Upstream commit 8f3cbcd6b440032ebc7f7d48a1689dcc70a4eb98 ]

Following by the below discussion, there's the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/

From the analysis of Yingliang

CPU A				|CPU B
mt6370_probe()			|
  devm_mfd_add_devices()	|
				|mt6370_regulator_probe()
				|  regulator_register()
				|    //allocate init_data and add it to devres
				|    regulator_of_get_init_data()
i2c_unregister_device()		|
  device_del()			|
    devres_release_all()	|
      // init_data is freed	|
      release_nodes()		|
				|  // using init_data causes UAF
				|  regulator_register()

It's common to use mfd core to create child device for the regulator.
In order to do the DT lookup for init data, the child that registered
the regulator would pass its parent as the parameter. And this causes
init data resource allocated to its parent, not itself. The issue happen
when parent device is going to release and regulator core is still doing
some operation of init data constraint for the regulator of child device.

To fix it, this patch expand 'regulator_register' API to use the
different devices for init data allocation and DT lookup.

Reported-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Signed-off-by: ChiYuan Huang &lt;cy_huang@richtek.com&gt;
Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/mellanox: mlxbf-pmc: Fix event typo</title>
<updated>2022-12-31T12:25:48+00:00</updated>
<author>
<name>James Hurley</name>
<email>jahurley@nvidia.com</email>
</author>
<published>2022-12-09T14:35:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4eedd23fab098b179280bcedd7234d66ba4e6f43'/>
<id>urn:sha1:4eedd23fab098b179280bcedd7234d66ba4e6f43</id>
<content type='text'>
[ Upstream commit b0b698b80c56b0712f0d4346d51bf0363ba03068 ]

Had a duplicate event typo, so just fixed the 1 character typo.

Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver")
Signed-off-by: James Hurley &lt;jahurley@nvidia.com&gt;
Reviewed-by: David Thompson &lt;davthompson@nvidia.com&gt;
Reviewed-by: Shravan Kumar Ramani &lt;shravankr@nvidia.com&gt;
Link: https://lore.kernel.org/r/aadacdbbd3186c55e74ea9456fe011b77938eb6c.1670535330.git.jahurley@nvidia.com
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: intel_scu_ipc: fix possible name leak in __intel_scu_ipc_register()</title>
<updated>2022-12-31T12:25:47+00:00</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2022-12-08T15:19:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=13787aeec78d1c0719ac9569fbf5d191b0499d5d'/>
<id>urn:sha1:13787aeec78d1c0719ac9569fbf5d191b0499d5d</id>
<content type='text'>
[ Upstream commit 0b3d0cb7c0bed2fd6454f77ed75e7a662c6efd12 ]

In some error paths before device_register(), the names allocated
by dev_set_name() are not freed. Move dev_set_name() front to
device_register(), so the name can be freed while calling
put_device().

Fixes: 54b34aa0a729 ("platform/x86: intel_scu_ipc: Split out SCU IPC functionality from the SCU driver")
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Link: https://lore.kernel.org/r/20221208151916.2404977-1-yangyingliang@huawei.com
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]()</title>
<updated>2022-12-31T12:25:47+00:00</updated>
<author>
<name>Yu Liao</name>
<email>liaoyu15@huawei.com</email>
</author>
<published>2022-11-29T01:11:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=379e7794c5e7485193d25d73614fbbd1e1387f6f'/>
<id>urn:sha1:379e7794c5e7485193d25d73614fbbd1e1387f6f</id>
<content type='text'>
[ Upstream commit 727cc0147f5066e359aca65cc6cc5e6d64cc15d8 ]

The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method()
is not freed after the call, so it leads to memory leak.

The method results in ACPI buffer is not used, so just pass NULL to
wmi_evaluate_method() which fixes the memory leak.

Fixes: 99b38b4acc0d ("platform/x86: add MXM WMI driver.")
Signed-off-by: Yu Liao &lt;liaoyu15@huawei.com&gt;
Link: https://lore.kernel.org/r/20221129011101.2042315-1-liaoyu15@huawei.com
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_typec: zero out stale pointers</title>
<updated>2022-12-31T12:25:47+00:00</updated>
<author>
<name>Victor Ding</name>
<email>victording@chromium.org</email>
</author>
<published>2022-12-07T09:39:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b610758bb3e0674644c1255cdafc2f46b7e05ff9'/>
<id>urn:sha1:b610758bb3e0674644c1255cdafc2f46b7e05ff9</id>
<content type='text'>
[ Upstream commit 9a8aadcf0b459c1257b9477fd6402e1d5952ae07 ]

`cros_typec_get_switch_handles` allocates four pointers when obtaining
type-c switch handles. These pointers are all freed if failing to obtain
any of them; therefore, pointers in `port` become stale. The stale
pointers eventually cause use-after-free or double free in later code
paths. Zeroing out all pointer fields after freeing to eliminate these
stale pointers.

Fixes: f28adb41dab4 ("platform/chrome: cros_ec_typec: Register Type C switches")
Fixes: 1a8912caba02 ("platform/chrome: cros_ec_typec: Get retimer handle")
Signed-off-by: Victor Ding &lt;victording@chromium.org&gt;
Acked-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Link: https://lore.kernel.org/r/20221207093924.v2.1.I1864b6a7ee98824118b93677868d22d3750f439b@changeid
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_typec: Get retimer handle</title>
<updated>2022-12-31T12:25:47+00:00</updated>
<author>
<name>Prashant Malani</name>
<email>pmalani@chromium.org</email>
</author>
<published>2022-08-16T21:48:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0aff64f9e1e3281438d07cfbdca4c87fcd2aad5c'/>
<id>urn:sha1:0aff64f9e1e3281438d07cfbdca4c87fcd2aad5c</id>
<content type='text'>
[ Upstream commit 1a8912caba02522f612d465a4849ce98915b96ad ]

Where available, obtain the handle to retimer switch specified via
firmware, and update the mux configuration callsites to add retimer
support for supported modes.

Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Reviewed-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Link: https://lore.kernel.org/r/20220816214857.2088914-8-pmalani@chromium.org
Stable-dep-of: 9a8aadcf0b45 ("platform/chrome: cros_ec_typec: zero out stale pointers")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_typec: Cleanup switch handle return paths</title>
<updated>2022-12-31T12:25:46+00:00</updated>
<author>
<name>Prashant Malani</name>
<email>pmalani@chromium.org</email>
</author>
<published>2022-08-16T21:48:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85da421e7594f75782e82e7c66a77d025094fbcb'/>
<id>urn:sha1:85da421e7594f75782e82e7c66a77d025094fbcb</id>
<content type='text'>
[ Upstream commit d5f66527db9e0e6a871d9005200b3394156cf16f ]

Some of the return paths for the cros_typec_get_switch_handles()
aren't necessary. Clean up the return paths to only undo the handle
get's which succeeded.

Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Reviewed-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Link: https://lore.kernel.org/r/20220816214857.2088914-7-pmalani@chromium.org
Stable-dep-of: 9a8aadcf0b45 ("platform/chrome: cros_ec_typec: zero out stale pointers")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()</title>
<updated>2022-12-31T12:25:44+00:00</updated>
<author>
<name>Yuan Can</name>
<email>yuancan@huawei.com</email>
</author>
<published>2022-11-17T08:08:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b6ee54995739202b4a0cc01b7e9269f761c573d'/>
<id>urn:sha1:7b6ee54995739202b4a0cc01b7e9269f761c573d</id>
<content type='text'>
[ Upstream commit 5a2d96623670155d94aca72c320c0ac27bdc6bd2 ]

The following WARNING message was given when rmmod cros_usbpd_notify:

 Unexpected driver unregister!
 WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0
 Modules linked in: cros_usbpd_notify(-)
 CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24
 ...
 Call Trace:
  &lt;TASK&gt;
  cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify]
  __x64_sys_delete_module+0x3c7/0x570
  ? __ia32_sys_delete_module+0x570/0x570
  ? lock_is_held_type+0xe3/0x140
  ? syscall_enter_from_user_mode+0x17/0x50
  ? rcu_read_lock_sched_held+0xa0/0xd0
  ? syscall_enter_from_user_mode+0x1c/0x50
  do_syscall_64+0x37/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
 RIP: 0033:0x7f333fe9b1b7

The reason is that the cros_usbpd_notify_init() does not check the return
value of platform_driver_register(), and the cros_usbpd_notify can
install successfully even if platform_driver_register() failed.

Fix by checking the return value of platform_driver_register() and
unregister cros_usbpd_notify_plat_driver when it failed.

Fixes: ec2daf6e33f9 ("platform: chrome: Add cros-usbpd-notify driver")
Signed-off-by: Yuan Can &lt;yuancan@huawei.com&gt;
Reviewed-by: Brian Norris &lt;briannorris@chromium.org&gt;
Link: https://lore.kernel.org/r/20221117080823.77549-1-yuancan@huawei.com
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: huawei-wmi: fix return value calculation</title>
<updated>2022-12-31T12:25:43+00:00</updated>
<author>
<name>Barnabás Pőcze</name>
<email>pobrn@protonmail.com</email>
</author>
<published>2022-10-05T15:00:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39d23a19a214cfa24bee64818132daa91b6e235c'/>
<id>urn:sha1:39d23a19a214cfa24bee64818132daa91b6e235c</id>
<content type='text'>
[ Upstream commit 0b9a1dcdb6a2c841899389bf2dd7a3e0e2aa0e99 ]

Previously, `huawei_wmi_input_setup()` returned the result of
logical or-ing the return values of two functions that return negative
errno-style error codes and one that returns `acpi_status`. If this
returned value was non-zero, then it was propagated from the platform
driver's probe function. That function should return a negative
errno-style error code, so the result of the logical or that
`huawei_wmi_input_setup()` returned was not appropriate.

Fix that by checking each function separately and returning the
error code unmodified.

Fixes: 1ac9abeb2e5b ("platform/x86: huawei-wmi: Move to platform driver")
Signed-off-by: Barnabás Pőcze &lt;pobrn@protonmail.com&gt;
Link: https://lore.kernel.org/r/20221005150032.173198-2-pobrn@protonmail.com
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/x86: asus-wmi: Add support for ROG X13 tablet mode</title>
<updated>2022-12-14T10:40:51+00:00</updated>
<author>
<name>Luke D. Jones</name>
<email>luke@ljones.dev</email>
</author>
<published>2022-08-13T09:27:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=65effdb79e6240aada7ae741f07cb69ec515d4a7'/>
<id>urn:sha1:65effdb79e6240aada7ae741f07cb69ec515d4a7</id>
<content type='text'>
[ Upstream commit e397c3c460bf3849384f2f55516d1887617cfca9 ]

Add quirk for ASUS ROG X13 Flow 2-in-1 to enable tablet mode with
lid flip (all screen rotations).

Signed-off-by: Luke D. Jones &lt;luke@ljones.dev&gt;
Link: https://lore.kernel.org/r/20220813092753.6635-2-luke@ljones.dev
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
