linux-stable.git/drivers/pnp, branch v6.7.4 Linux kernel stable tree PNP: ACPI: fix fortify warning 2024-02-05T20:16:45+00:00 Dmitry Antipov dmantipov@yandex.ru 2023-11-28T02:52:10+00:00 1fa669da8f22f1d35f1bc7bd1e8be7a70c0f605f [ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ] When compiling with gcc version 14.0.0 20231126 (experimental) and CONFIG_FORTIFY_SOURCE=y, I've noticed the following: In file included from ./include/linux/string.h:295, from ./include/linux/bitmap.h:12, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/paravirt.h:17, from ./arch/x86/include/asm/cpuid.h:62, from ./arch/x86/include/asm/processor.h:19, from ./arch/x86/include/asm/cpufeature.h:5, from ./arch/x86/include/asm/thread_info.h:53, from ./include/linux/thread_info.h:60, from ./arch/x86/include/asm/preempt.h:9, from ./include/linux/preempt.h:79, from ./include/linux/spinlock.h:56, from ./include/linux/mmzone.h:8, from ./include/linux/gfp.h:7, from ./include/linux/slab.h:16, from ./include/linux/resource_ext.h:11, from ./include/linux/acpi.h:13, from drivers/pnp/pnpacpi/rsparser.c:11: In function 'fortify_memcpy_chk', inlined from 'pnpacpi_parse_allocated_vendor' at drivers/pnp/pnpacpi/rsparser.c:158:3, inlined from 'pnpacpi_allocated_resource' at drivers/pnp/pnpacpi/rsparser.c:249:3: ./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field' declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 588 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ According to the comments in include/linux/fortify-string.h, 'memcpy()', 'memmove()' and 'memset()' must not be used beyond individual struct members to ensure that the compiler can enforce protection against buffer overflows, and, IIUC, this also applies to partial copies from the particular member ('vendor->byte_data' in this case). So it should be better (and safer) to do both copies at once (and 'byte_data' of 'struct acpi_resource_vendor_typed' seems to be a good candidate for '__counted_by(byte_length)' as well). Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ]

When compiling with gcc version 14.0.0 20231126 (experimental)
and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:

In file included from ./include/linux/string.h:295,
                 from ./include/linux/bitmap.h:12,
                 from ./include/linux/cpumask.h:12,
                 from ./arch/x86/include/asm/paravirt.h:17,
                 from ./arch/x86/include/asm/cpuid.h:62,
                 from ./arch/x86/include/asm/processor.h:19,
                 from ./arch/x86/include/asm/cpufeature.h:5,
                 from ./arch/x86/include/asm/thread_info.h:53,
                 from ./include/linux/thread_info.h:60,
                 from ./arch/x86/include/asm/preempt.h:9,
                 from ./include/linux/preempt.h:79,
                 from ./include/linux/spinlock.h:56,
                 from ./include/linux/mmzone.h:8,
                 from ./include/linux/gfp.h:7,
                 from ./include/linux/slab.h:16,
                 from ./include/linux/resource_ext.h:11,
                 from ./include/linux/acpi.h:13,
                 from drivers/pnp/pnpacpi/rsparser.c:11:
In function 'fortify_memcpy_chk',
    inlined from 'pnpacpi_parse_allocated_vendor' at drivers/pnp/pnpacpi/rsparser.c:158:3,
    inlined from 'pnpacpi_allocated_resource' at drivers/pnp/pnpacpi/rsparser.c:249:3:
./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field'
declared with attribute warning: detected read beyond size of field (2nd parameter);
maybe use struct_group()? [-Wattribute-warning]
  588 |                         __read_overflow2_field(q_size_field, size);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

According to the comments in include/linux/fortify-string.h, 'memcpy()',
'memmove()' and 'memset()' must not be used beyond individual struct
members to ensure that the compiler can enforce protection against
buffer overflows, and, IIUC, this also applies to partial copies from
the particular member ('vendor->byte_data' in this case). So it should
be better (and safer) to do both copies at once (and 'byte_data' of
'struct acpi_resource_vendor_typed' seems to be a good candidate for
'__counted_by(byte_length)' as well).

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PNP: replace deprecated strncpy() with memcpy() 2023-10-20T17:50:40+00:00 Justin Stitt justinstitt@google.com 2023-10-19T23:28:32+00:00 50cbdaf1b93a2cc89d7712feafa76cf1b2f28adc strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous interfaces. After having precisely calculated the lengths and ensuring we don't overflow the buffer, this really decays to just a memcpy. Let's not use a C string api as it makes the intention of the code confusing. It'd be nice to use strscpy() in this case (as we clearly want NUL-termination) because it'd clean up the code a bit. However, I don't quite know enough about what is going on here to justify a drop-in replacement -- too much bit magic and why (PNP_NAME_LEN - 2)? I'm afraid using strscpy() may result in copying too many or too few bytes into our dev->name buffer resulting in different behavior. At least using memcpy() we can ensure the behavior is exactly the same. Side note: NUL-padding is not required because insert_device() calls pnpbios_parse_data_stream() with a zero-allocated `dev`: 299 | static int __init insert_device(struct pnp_bios_node *node) { ... 312 | dev = pnp_alloc_dev(&pnpbios_protocol, node->handle, id); ... 316 | pnpbios_parse_data_stream(dev, node); then pnpbios_parse_data_stream() calls pnpbios_parse_compatible_ids(). Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous
interfaces.

After having precisely calculated the lengths and ensuring we don't
overflow the buffer, this really decays to just a memcpy. Let's not use
a C string api as it makes the intention of the code confusing.

It'd be nice to use strscpy() in this case (as we clearly want
NUL-termination) because it'd clean up the code a bit. However, I don't
quite know enough about what is going on here to justify a drop-in
replacement -- too much bit magic and why (PNP_NAME_LEN - 2)? I'm afraid
using strscpy() may result in copying too many or too few bytes into our
dev->name buffer resulting in different behavior. At least using
memcpy() we can ensure the behavior is exactly the same.

Side note:
NUL-padding is not required because insert_device() calls
pnpbios_parse_data_stream() with a zero-allocated `dev`:
299 |  static int __init insert_device(struct pnp_bios_node *node) {
...
312 |  dev = pnp_alloc_dev(&pnpbios_protocol, node->handle, id);
...
316 |  pnpbios_parse_data_stream(dev, node);

then pnpbios_parse_data_stream() calls pnpbios_parse_compatible_ids().

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PNP: ACPI: replace deprecated strncpy() with strscpy() 2023-10-20T17:48:11+00:00 Justin Stitt justinstitt@google.com 2023-10-19T22:47:58+00:00 eda1a74655ea282fcac56af5ca18ff1394542e29 strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We know dev->name should be NUL-terminated based on the presence of a manual NUL-byte assignment. NUL-padding is not required as dev is already zero-allocated which renders any further NUL-byte assignments redundant: dev = pnp_alloc_dev(&pnpacpi_protocol, num, pnpid); ---> dev = kzalloc(sizeof(struct pnp_dev), GFP_KERNEL); Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. This simplifies the code and makes the intent/behavior more obvious. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.

We know dev->name should be NUL-terminated based on the presence of a
manual NUL-byte assignment.

NUL-padding is not required as dev is already zero-allocated which
renders any further NUL-byte assignments redundant:
dev = pnp_alloc_dev(&pnpacpi_protocol, num, pnpid); --->
  dev = kzalloc(sizeof(struct pnp_dev), GFP_KERNEL);

Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding. This simplifies the code and makes
the intent/behavior more obvious.

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PNP: ACPI: Fix string truncation warning 2023-08-17T17:38:35+00:00 Sunil V L sunilvl@ventanamicro.com 2023-07-25T05:29:25+00:00 99c31bff185610304532c4acf00cda341572e2d4 LKP reports below warning when building for RISC-V. drivers/pnp/pnpacpi/core.c:253:17: warning: 'strncpy' specified bound 50 equals destination size [-Wstringop-truncation] This appears to be a valid issue since the destination string may not be null-terminated. To fix this, append the NUL explicitly after the strncpy(). Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307241942.Rff2Nri5-lkp@intel.com/ Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
LKP reports below warning when building for RISC-V.

drivers/pnp/pnpacpi/core.c:253:17:
warning: 'strncpy' specified bound 50 equals destination
size [-Wstringop-truncation]

This appears to be a valid issue since the destination string may not be
null-terminated.

To fix this, append the NUL explicitly after the strncpy().

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202307241942.Rff2Nri5-lkp@intel.com/
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PCI: Introduce pci_dev_for_each_resource() 2023-04-04T15:43:52+00:00 Mika Westerberg mika.westerberg@linux.intel.com 2023-03-30T16:24:30+00:00 09cc900632400079619e9154604fd299c2cc9a5a Instead of open-coding it everywhere introduce a tiny helper that can be used to iterate over each resource of a PCI device, and convert the most obvious users into it. While at it drop doubled empty line before pdev_sort_resources(). No functional changes intended. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230330162434.35055-4-andriy.shevchenko@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> 
Instead of open-coding it everywhere introduce a tiny helper that can be
used to iterate over each resource of a PCI device, and convert the most
obvious users into it.

While at it drop doubled empty line before pdev_sort_resources().

No functional changes intended.

Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230330162434.35055-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
PNP: Do not disable devices on suspend when they cannot be re-enabled on resume 2022-11-25T18:36:52+00:00 Hans de Goede hdegoede@redhat.com 2022-11-24T10:53:05+00:00 62a0ec9dc1dfb0f58138f1e2527e4a26567268e5 On an Advantech MICA-071 tablet, with a builtin barcode scanner connected to ttyS0, the following message is shown on suspend: serial 00:02: disabled And after suspend/resume trying to use the barcode scanner / ttyS0 shows: serial 00:02: LSR safety check engaged! Indicating that the UARTs io-ports are no longer reachable. This is caused by __pnp_bus_suspend() calling pnp_stop_dev() on the "00:02" pnp device on suspend (this outputs the disabled message). The problem is that pnp_can_write() returns false for the "00:02" pnp device, so after disabling it (disabling its decoding of IO addresses) during suspend, it cannot be re-enabled. Add a pnp_can_write() check to the suspend path and only disable devices which can actually be re-enabled on resume. This fixes the Advantech MICA-071's ttyS0 no longer working after a suspend/resume. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
On an Advantech MICA-071 tablet, with a builtin barcode scanner connected
to ttyS0, the following message is shown on suspend:

serial 00:02: disabled

And after suspend/resume trying to use the barcode scanner / ttyS0 shows:

serial 00:02: LSR safety check engaged!

Indicating that the UARTs io-ports are no longer reachable.

This is caused by __pnp_bus_suspend() calling pnp_stop_dev() on the "00:02"
pnp device on suspend (this outputs the disabled message).

The problem is that pnp_can_write() returns false for the "00:02" pnp
device, so after disabling it (disabling its decoding of IO addresses)
during suspend, it cannot be re-enabled.

Add a pnp_can_write() check to the suspend path and only disable devices
which can actually be re-enabled on resume.

This fixes the Advantech MICA-071's ttyS0 no longer working after
a suspend/resume.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PNP: fix name memory leak in pnp_alloc_dev() 2022-11-22T19:37:21+00:00 Yang Yingliang yangyingliang@huawei.com 2022-11-11T01:23:58+00:00 110d7b0325c55ff3620073ba4201845f59e22ebf After commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, move dev_set_name() after pnp_add_id() to avoid memory leak. Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
After commit 1fa5ae857bb1 ("driver core: get rid of struct device's
bus_id string array"), the name of device is allocated dynamically,
move dev_set_name() after pnp_add_id() to avoid memory leak.

Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branches 'acpi-apei', 'acpi-wakeup', 'acpi-reboot' and 'acpi-thermal' 2022-10-10T16:11:11+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2022-10-10T16:11:11+00:00 056a81549c2722f0e7a9cceb7a98728eb1d67434 Merge additional APEI changes, ACPI updates related to device wakeup and system restart and ACPI thermal driver cleanups for 6.1-rc1: - Fix a memory leak in APEI by avoiding to add do not add task_work to kernel threads running when an asynchronous error is detected (Shuai Xue). - Add ACPI support for handling system wakeups via GPIO wake capable IRQs in addition to GPEs (Raul E Rangel). - Make the system reboot code put ACPI-enabled systems into the S5 (system off) state which is necessary for some platforms to work as expected (Kai-Heng Feng). - Make the white space usage in the ACPI thermal driver more consistent and drop redundant code from it (Rafael Wysocki). * acpi-apei: ACPI: APEI: do not add task_work to kernel thread to avoid memory leak * acpi-wakeup: ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idle i2c: acpi: Use ACPI wake capability bit to set wake_irq ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags gpiolib: acpi: Add wake_capable variants of acpi_dev_gpio_irq_get * acpi-reboot: PM: ACPI: reboot: Reinstate S5 for reboot kernel/reboot: Add SYS_OFF_MODE_RESTART_PREPARE mode * acpi-thermal: ACPI: thermal: Drop some redundant code ACPI: thermal: Drop redundant parens from expressions ACPI: thermal: Use white space more consistently 
Merge additional APEI changes, ACPI updates related to device wakeup and
system restart and ACPI thermal driver cleanups for 6.1-rc1:

 - Fix a memory leak in APEI by avoiding to add do not add task_work to
   kernel threads running when an asynchronous error is detected (Shuai
   Xue).

 - Add ACPI support for handling system wakeups via GPIO wake capable
   IRQs in addition to GPEs (Raul E Rangel).

 - Make the system reboot code put ACPI-enabled systems into the S5
   (system off) state which is necessary for some platforms to work as
   expected (Kai-Heng Feng).

 - Make the white space usage in the ACPI thermal driver more consistent
   and drop redundant code from it (Rafael Wysocki).

* acpi-apei:
  ACPI: APEI: do not add task_work to kernel thread to avoid memory leak

* acpi-wakeup:
  ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idle
  i2c: acpi: Use ACPI wake capability bit to set wake_irq
  ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags
  gpiolib: acpi: Add wake_capable variants of acpi_dev_gpio_irq_get

* acpi-reboot:
  PM: ACPI: reboot: Reinstate S5 for reboot
  kernel/reboot: Add SYS_OFF_MODE_RESTART_PREPARE mode

* acpi-thermal:
  ACPI: thermal: Drop some redundant code
  ACPI: thermal: Drop redundant parens from expressions
  ACPI: thermal: Use white space more consistently
ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags 2022-10-04T13:41:12+00:00 Raul E Rangel rrangel@chromium.org 2022-09-29T16:19:10+00:00 5ff811604f93bdd2650beed80b48c2ca16c6fba6 ACPI IRQ/Interrupt resources contain a bit that describes if the interrupt should wake the system. This change exposes that bit via a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag before arming an IRQ to wake the system. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
ACPI IRQ/Interrupt resources contain a bit that describes if the
interrupt should wake the system. This change exposes that bit via
a new IORESOURCE_IRQ_WAKECAPABLE flag. Drivers should check this flag
before arming an IRQ to wake the system.

Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PNPBIOS: remove unused pnpid32_to_pnpid() declaration 2022-09-24T16:07:42+00:00 Gaosheng Cui cuigaosheng1@huawei.com 2022-09-14T01:33:17+00:00 564d53b8b5909ce7a23106873aaf4c4496c3df10 All uses of pnpid32_to_pnpid() were removed by commit 25eb846189d2 ("PNP: add pnp_eisa_id_to_string()"), so remove the declaration, too. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
All uses of pnpid32_to_pnpid() were removed by
commit 25eb846189d2 ("PNP: add pnp_eisa_id_to_string()"),
so remove the declaration, too.

Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>