The existing coreboot_table_populate() bounds checks limit individual
entries to the mapped length. However, coreboot_table_probe() replaces
the platform resource length with header and table sizes supplied by
firmware before mapping the full table.
A malformed table can overflow the 32-bit size addition or advertise an
extent beyond the resource, causing the driver to map and parse memory
outside the resource. A resource shorter than the fixed header is also
mapped as though it contained a complete header.
Reject resources shorter than the fixed header. After validating the
signature, require a complete header, calculate the advertised extent
with overflow checking, and reject extents beyond the resource before
remapping the table.
Fixes: d384d6f43d1e ("firmware: google memconsole: Add coreboot support")
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com>
Link: https://lore.kernel.org/r/20260801165651.42172-1-acharyalaxman8848@gmail.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
On ARM64 platforms, certain reserved memory regions (like those used by pKVM) are marked with the 'no-map' property. This indicates that the host kernel is forbidden from creating a structural mapping for these regions. The coreboot table may describe CBMEM entries that overlap with or are entirely contained within these no-map regions. Attempting to populate these entries as devices and subsequently remapping them can lead to system crashes or security violations. Refine the coreboot table population logic to verify that each CBMEM entry resides in 'Known Good' memory before creating a device. An entry is only considered safe if it is entirely System RAM or entirely standard Reserved memory (tagged with IORES_DESC_RESERVED). This dual-check ensures that: 1. On ARM64, no-map regions are filtered out as they are IORESOURCE_MEM (see request_standard_resources() in arch/arm64/kernel/setup.c). 2. On x86, standard reserved regions (IORES_DESC_RESERVED) remain supported. Signed-off-by: Yidi Lin <yidilin@google.com> Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Link: https://lore.kernel.org/r/20260717-coreboot-v2-1-8f8b389e3758@chromium.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Replace the #include of <linux/mod_devicetable.h> by the more specific <linux/device-id/*.h> where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
coreboot_table_populate() registers devices one by one. If device_register() fails for one entry, the current code returns immediately, leaving previously registered devices orphaned on the coreboot bus with no cleanup path. Since coreboot table entries are independent of each other, a failure on one entry should not prevent the others from being registered. This mirrors the strategy used by of_platform_populate(), which skips individual failures rather than aborting. Move ptr_entry increment before device_register(), log a warning on failure, and continue the loop rather than aborting. Signed-off-by: Titouan Ameline de Cadeville <titouan.ameline@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20260501094322.123160-1-titouan.ameline@gmail.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
coreboot_table_populate() iterates over firmware-provided table entries with no validation that the entries stay within the mapped memory region. A corrupt table with a large `entry->size` advances `ptr_entry` past the mapped region, causing an out-of-bounds read on the next iteration. Add a check before dereferencing `ptr_entry` to ensure the entry header is readable, and a second check after reading `entry->size` to ensure the full entry stays within the mapped region. Pass `len` from coreboot_table_probe() into coreboot_table_populate() to make the mapped region size available for validation. Signed-off-by: Titouan Ameline de Cadeville <titouan.ameline@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Link: https://lore.kernel.org/r/20260426214739.117131-1-titouan.ameline@gmail.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Let's merge 7.0-rc1 to start the new drm-misc-next window Signed-off-by: Maxime Ripard <mripard@kernel.org>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
Add corebootdrm, a DRM driver for coreboot framebuffers. The driver supports a pre-initialized framebuffer with various packed RGB formats. The driver code is fairly small and uses the same logic as the other sysfb drivers. Most of the implementation comes from existing sysfb helpers. Until now, coreboot relied on simpledrm or simplefb for boot-up graphics output. Initialize the platform device for corebootdrm in the same place in framebuffer_probe(). With a later commit, the simple-framebuffer should be removed. v4: - sort include statements (Tzung-Bi) v3: - comment on _HAS_LFB semantics (Tzung-Bi) - fix typo in commit description (Tzung-Bi) - comment on simple-framebuffer being obsolete for coreboot v2: - reimplement as platform driver - limit resources and mappings to known framebuffer memory; no page alignment - create corebootdrm device from coreboot framebuffer code Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Julius Werner <jwerner@chromium.org> Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> # coreboot Link: https://patch.msgid.link/20260217155836.96267-12-tzimmermann@suse.de
Move types for coreboot table entries to <linux/coreboot.h>. Allows drivers in other subsystems to use these structures. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> Acked-by: Julius Werner <jwerner@chromium.org> Link: https://patch.msgid.link/20260217155836.96267-9-tzimmermann@suse.de