| Age | Commit message (Collapse) | Author |
|---|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Signed-off-by: Helge Deller <deller@gmx.de>
Noticed-by: Breno Rodrigues Alves <breno3011alves@gmail.com>
|
|
sstfb_probe() enables the PCI device with pci_enable_device(), but
failure paths after that point return without disabling it. The successful
probe path has the same imbalance because sstfb_remove() releases the
framebuffer, mappings and memory regions, but never calls
pci_disable_device().
Use pcim_enable_device() so the PCI core disables the device automatically
after probe failure or driver removal. The driver still releases its
framebuffer, mappings and memory regions explicitly.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The acornfb driver contains code to support machines with a MEMC chip
and without IOMD and VIDC20 chips. All 32-bit Acorn hardware has IOMD
and VIDC20 chips and does not have a MEMC chip.
Linux formerly supported 26-bit Acorn computers, but that support was
removed in commit 99eb8a550dbc ("Remove the arm26 port") because it had
bitrotted to the extent that it did not even compile.
Remove this unused code. Also take the opportunity to remove incorrect
file paths in the file headers, which are bad style regardless.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Failures in nvidia_set_fbinfo() or register_framebuffer() leave the handle
from arch_phys_wc_add() allocated. Release it in the shared error path,
as nvidiafb_remove() already does on normal removal.
The missing cleanup was already present in the initial Git import,
when the driver used mtrr_add() directly.
This issue was identified during our ongoing static-analysis research
while reviewing kernel code.
Cc: stable@vger.kernel.org
Assisted-by: LLM
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
If register_framebuffer() fails, kyrofb_probe() frees the framebuffer
without releasing its write-combining range. Release the range before
freeing the framebuffer. Earlier failures still skip this cleanup.
The missing cleanup already exists in the initial Git import, before
the conversion from mtrr_add() to arch_phys_wc_add().
This issue was identified during our ongoing static-analysis research
while reviewing kernel code.
Cc: stable@vger.kernel.org
Assisted-by: LLM
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
gxt4500_probe() adds a write-combining range before allocating the cmap
and registering the framebuffer. If a later step fails, the range is
not released. Add the missing cleanup before unmapping the framebuffer,
matching the successful remove path.
This issue was identified during our ongoing static-analysis research
while reviewing kernel code.
Fixes: 38fc4d45fae5 ("gxt4500: Use arch_phys_wc_* for framebuffer")
Assisted-by: LLM
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The LCD controller IRQ schedules sinfo->task to recover from a FIFO
underflow. Probe currently requests the IRQ before initializing the
work, so an early interrupt can schedule an uninitialized work item.
The probe error path and remove path cancel the work before freeing the
IRQ. A FIFO-underflow interrupt can schedule the work again after that
cancellation. framebuffer_release() may then free sinfo while the work
is still pending.
KASAN reported a use-after-free in atmel_lcdfb_task() when an underflow
interrupt occurred during removal. With the IRQ freed before the work
was cancelled, the same test completed without a kernel diagnostic.
Initialize the work before requesting the IRQ. In both cleanup paths,
free the IRQ before cancelling the work so that it cannot be scheduled
again after cancellation.
Fixes: d22579b83735 ("atmel_lcdfb: FIFO underflow management")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently sh_mobile_lcdc_start() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due
to an allocation failure) info->fbdefio_state is left NULL.
When the file is subsequently opened, fb_open() will dereference a NULL
pointer (calling fb_deferred_io_open()).
Fix this by checking for the error.
Also clear info->fbdefio in that case, so that sh_mobile_lcdc_stop() does
not attempt to clean up deferred I/O state that was never initialised.
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently ufx_ops_open() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due to
an allocation failure) info->fbdefio_state is left NULL.
fb_open() will then dereference a NULL pointer (calling
fb_deferred_io_open()) as soon as ufx_ops_open() returns.
Additionally, if the allocation of info->fbdefio itself fails,
ufx_ops_open() sets info->fbdefio to NULL and invokes
fb_deferred_io_init() regardless, hitting BUG_ON(!fbdefio).
Fix this by only invoking fb_deferred_io_init() if the allocation
succeeded, and checking for the error.
The driver already supports operating without deferred I/O, so in either
case fall back to that by setting info->fbdefio to NULL.
The ignored return value was introduced in commit 56c134f7f1b5 ("fbdev:
Track deferred-I/O pages in pageref struct").
However, the BUG_ON() issue originates from the earlier
commit 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display
adapters"), so target that for the fix.
Fixes: 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display adapters")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently dlfb_ops_open() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due to
an allocation failure) info->fbdefio_state is left NULL.
fb_open() will then dereference a NULL pointer (calling
fb_deferred_io_open()) as soon as dlfb_ops_open() returns.
Additionally, if the allocation of info->fbdefio itself fails,
dlfb_ops_open() sets info->fbdefio to NULL and invokes
fb_deferred_io_init() regardless, hitting BUG_ON(!fbdefio).
Fix this by only invoking fb_deferred_io_init() if the allocation
succeeded, and checking for the error.
The driver already supports operating without deferred I/O, so in either
case fall back to that by setting info->fbdefio to NULL.
The ignored return value was introduced in commit 56c134f7f1b5 ("fbdev:
Track deferred-I/O pages in pageref struct").
However, the BUG_ON() issue originates from the earlier
commit 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio
implementation for multiple framebuffers"), so target that for the fix.
Fixes: 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio implementation for multiple framebuffers")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently picolcd_init_framebuffer() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due
to an allocation failure) info->fbdefio_state is left NULL.
When the file is subsequently opened, fb_open() will dereference a NULL
pointer (calling fb_deferred_io_open()).
Fix this by checking for the error.
Also correct cleanup ordering - defio is initialised after the sysfs file,
so cleanup defio first.
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently xenfb_probe() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due
to an allocation failure) info->fbdefio_state is left NULL.
When the file is subsequently opened, fb_open() will dereference a NULL
pointer (calling fb_deferred_io_open()).
Fix this by checking for the error.
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently ssd1307fb_probe() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due
to an allocation failure) info->fbdefio_state is left NULL.
When the file is subsequently opened, fb_open() will dereference a NULL
pointer (calling fb_deferred_io_open()).
Fix this by checking for the error.
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
framebuffer_alloc() returns zeroed memory, so info->modelist starts out
with NULL next and prev pointers. The list head is initialized only
later, by fb_videomode_to_modelist() or by do_register_framebuffer().
The "fix potential memory leak" commits listed below added
fb_destroy_modelist(&info->modelist) to the probe error paths of s3fb,
tdfxfb, tridentfb, i740fb and carminefb. These paths can run before
the list head is initialized:
- s3fb, tdfxfb, tridentfb and i740fb call fb_videomode_to_modelist()
only after a successful EDID read, and tridentfb can also hit the
error path on an ioremap() or kmalloc() failure before that;
- carminefb jumps to the error path when fb_find_mode() fails, before
its fb_videomode_to_modelist() call.
fb_destroy_modelist() then dereferences the NULL head. Reproduced on
Debian 12 (6.1.180) by binding s3fb to a VGA device without EDID and
forcing fb_alloc_cmap() to fail:
s3fb 0000:00:03.0: cannot allocate colormap
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:fb_destroy_modelist+0x10/0x80
Call Trace:
s3_pci_probe.cold+0x12b/0x2bf [s3fb]
local_pci_probe+0x41/0x80
pci_device_probe+0xc3/0x240
really_probe+0xde/0x380
__driver_probe_device+0x84/0x150
driver_probe_device+0x1f/0x90
__driver_attach+0xce/0x1c0
bus_for_each_dev+0x87/0xd0
bus_add_driver+0x1ae/0x200
driver_register+0x89/0xe0
do_one_initcall+0x59/0x220
do_init_module+0x4a/0x1f0
Initialize the list head in framebuffer_alloc(), so info->modelist is
always a valid, possibly empty, list and fb_destroy_modelist() is safe
on every error path. Keep the lazy initialization in
do_register_framebuffer(), as drivers that embed struct fb_info rather
than calling framebuffer_alloc() still depend on it.
Fixes: 3b0ed04bc852 ("fbdev: s3fb: fix potential memory leak in s3_pci_probe()")
Fixes: bb019d755366 ("fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()")
Fixes: 7a35ec619d9a ("fbdev: tridentfb: fix potential memory leak in trident_pci_probe()")
Fixes: 5936063409af ("fbdev: i740fb: fix potential memory leak in i740fb_probe()")
Fixes: 6fcca16a2b19 ("fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()")
Cc: stable@vger.kernel.org
Signed-off-by: Andrey Misiurov <andrey.misyrov@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
dlfb_setup_modes() frees info->modelist with fb_destroy_modelist() and
rebuilds it, but fbcon holds raw pointers into that list in
fb_display[i].mode and nothing un-publishes them the way
do_unregister_framebuffer() and store_modes() do with
fbcon_delete_modelist(). The function does refuse to install a new mode
while the framebuffer has users (dlfb->fb_count != 0), but only after the
list is already destroyed. Reached from the 0666 "edid" sysfs attribute,
an unprivileged write to /sys/class/graphics/fb0/edid therefore fails with
-EINVAL and still leaves every fb_display[i].mode dangling; the next
console switch reads the freed fb_videomode in fb_videomode_to_var().
Test fb_count before touching the list. fbcon takes a reference through
fbcon_open(), so that condition covers exactly the states in which
fb_display[] points into the list, and the errno returned to userspace is
unchanged.
BUG: KASAN: slab-use-after-free in fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905)
Read of size 4 at addr ffff8880107b449c by task kworker/1:1/47
Workqueue: events console_callback
Call Trace:
fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905)
display_to_var (drivers/video/fbdev/core/fbcon.c:998)
fbcon_switch (drivers/video/fbdev/core/fbcon.c:2182)
redraw_screen (drivers/tty/vt/vt.c:994)
complete_change_console (drivers/tty/vt/vt_ioctl.c:1141)
console_callback (drivers/tty/vt/vt.c:3358)
process_one_work (kernel/workqueue.c:3396)
worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
...
The buggy address is located 28 bytes inside of
freed 96-byte region [ffff8880107b4480, ffff8880107b44e0)
Cc: stable@vger.kernel.org
Fixes: 7d9485e2c53c ("Staging: udlfb: Add functions to expose sysfs metrics and controls")
Reported-by: co+ed9902f2e44184d9@bugs.sh
Closes: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/
Assisted-by: Claude:claude-opus-5
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
The ovl_* files documented in
Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb no
longer exist.
Commit a979182a2453 ("fbdev: lcdcfb: Register sysfs groups through driver
core") moved the attributes from each overlay's framebuffer device to
the platform driver's dev_groups and renamed them overlay_*. There is
now only one set of attributes for the whole LCDC. The callbacks still
expect dev_get_drvdata() to return a struct fb_info, but the platform
device holds struct sh_mobile_lcdc_priv, so they access the wrong
structure.
Restore the documented names and register the group on each overlay's
framebuffer device with device_add_groups(). Remove it with
device_remove_groups() before unregistering the framebuffer. Skip
creation when dev_of_fbinfo(info) is NULL, as the old device_create_file()
calls did.
Drop the CONFIG_FB_DEVICE guard, since the driver already depends on it.
Fixes: a979182a2453 ("fbdev: lcdcfb: Register sysfs groups through driver core")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next
DRM Rust changes for v7.4-rc1
- Cross-subsystem:
- I/O (shared from driver-core tree via signed tag rust-io-7.4-rc1):
- Reimplement register!() as a procedural macro, require matching
base types for register access, and replace relative registers
with typed I/O projections. Convert Nova, Tyr and the PCI sample
- Add AsRepr/AsReprMut conversions for I/O on compatible wrapper
types and transmute helpers with deferred size checks
- DMA (shared from driver-core tree via signed tag rust-dma-7.4-rc1):
- Tie Coherent, CoherentBox and CoherentHandle to the device's bound
lifetime, and allow scoped debugfs files backed by non-'static
data
- Allow auxiliary registration-data closures to return covariant
sub-fields and add UserSliceWriter::write_truncated()
- Implement Send and Sync for MapleTree
- Add PCI resource_flags() and IORESOURCE_MEM_64, and convert PCI IRQ
flags to impl_flags!()
- Add I/O view cast() with compile-time size and alignment checks
- DRM:
- Add Rust dma_fence abstractions with separate producer (DriverFence)
and consumer (Fence) types, per-context sequencing, signal callbacks
and preallocation. Additional backend operations remain follow-up
work.
- Initialize DRM registrations and their data in place, removing a
separate allocation
- Drop the unused flags argument from drm::Registration::new()
- Nova:
- UAPI and Cross Module API:
- Add NovaCoreApi and a lifetime-bound handle for auxiliary child
drivers, carried in nova-drm registration data
- Expose a render node and extensible INFO ioctl reporting GPU
architecture, opaque chip ID, usable VRAM and VRAM BAR sizes,
full and short GPU names, and GID, with size discovery and
truncation to the userspace buffer size
- Move BAR-size queries into GPU info, removing GETPARAM and
changing the UAPI
- PRAMIN access:
- Add typed CPU access to VRAM through the movable 1 MiB BAR0
PRAMIN window, with per-architecture support from Turing through
Blackwell
- Add GpuMm centralized memory manager, VramAddress type, aperture
documentation and optional probe-time self-tests under
CONFIG_NOVA_CORE_SELFTESTS
- GPU virtual memory and BAR1:
- Add VRAM buddy allocation, TLB flushing, MMU v2/v3 page-table
types with trait-based generics (PteOps, PdeOps, DualPdeOps,
MmuConfig) and a generic walker
- Add maple-tree virtual address tracking and multi-page mapping,
separating allocation from mapping execution
- Add CPU access to mapped VRAM through BAR1 and memory-management
self-tests; handle 64-bit BAR0 when locating BAR1
- GPU interrupts and GSP events:
- Add GIN (GPU Interrupt and Notification) interrupt-tree support
with MSI-X, MSI fallback and per-architecture rearming
- Drain GSP events between commands via a threaded SWGEN0 handler
- Report OS errors, robust-channel notifications and unknown
messages without aborting command waits; hold the queue lock and
use one deadline per wait
- Disable GSP event interrupts on persistent falcon faults or
drain errors
- Add a delivery/rearm self-test, interrupt-tree KUnit coverage
and interrupt-controller documentation
- GSP messaging fixes:
- Queue setup RPCs before GSP-RM boot
- Correct DMA barriers in both queue directions
- Firmware and transport:
- Extract a reusable radix3 buffer mapper; zero-pad page-table
levels to whole pages to prevent booter reads of stale padding
- Correct GSP-FMC naming and boot-flow documentation
- Set MCTP header version 1 for FSP messages and retain the
command queue's BAR0 reference
- Resource handling:
- Replace unnecessary BarUser reference counting with in-place
ownership and borrowed access; consolidate probe initialization
- Declare an unlimited DMA maximum segment size
- Tyr:
- Use bitfield!() for firmware section flags and memory attributes
that do not describe registers
- Zero unsupported and newly added GPU-info fields, and limit the
doorbell array to 17 entries to fit the mapped register region
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: "Danilo Krummrich" <dakr@kernel.org>
Link: https://patch.msgid.link/DM371PN4TBJT.3LY1B0EYWSI4@kernel.org
|
|
ttm_bo_type_kernel BOs are not guaranteed to be zeroed on allocation and
may contain data from previously freed pages. Since the OA buffer is
mmap'able by userspace, this can expose stale kernel memory contents.
Streams opened with DRM_XE_OA_PROPERTY_OA_DISABLED allocate the OA
buffer without calling xe_oa_init_oa_buffer(). Zero the buffer at
allocation to prevent information disclosure through mmap.
The existing zeroing in xe_oa_init_oa_buffer() remains necessary for
zero report-id/timestamp detection on enable/re-enable.
Fixes: 392bf22238ff ("drm/xe/oa/uapi: OA buffer mmap")
Assisted-by: LLM
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Ghimiray, Himal Prasad <himal.prasad.ghimiray@intel.com>
Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Link: https://patch.msgid.link/20261006020314.2711762-1-krishnaiah.bommu@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
|
|
Exercise the xe_evict_flags() NULL-resource path: import a dma-buf, gut
the importer to an empty placement so it drops its resource, then drive
the real xe_dma_buf_move_notify() -> xe_bo_evict() path and verify it no
longer faults.
Assisted-by: GitHub-Copilot:claude-opus-4.8
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20261012215014.1495677-6-niranjana.vishwanathapura@intel.com
|
|
xe_evict_flags() switches on tbo->resource->mem_type to choose an
eviction placement. An xe BO can reach eviction with no ttm.resource,
e.g. an imported dma-buf BO whose resource was freed during teardown
while its attachment is still live: the exporter then invalidates it via
xe_dma_buf_move_notify() -> xe_bo_evict(), and the switch dereferences a
NULL resource and faults.
A BO with no resource has nothing placed or mapped, so there is nothing
to evict. Return an empty placement (num_placement = 0), mirroring the
handling already used for non-xe scatter-gather BOs just above;
ttm_bo_validate() then takes the pipeline-gutting path and returns 0.
Without the fix the xe_dma_buf@xe_test_dmabuf_move_notify_no_resource
dynamic live selftest will fail with below stack.
BUG: kernel NULL pointer dereference, address: 0000000000000010
RIP: 0010:xe_evict_flags+0xf4/0x140 [xe]
Call Trace:
<TASK>
xe_bo_evict+0x40/0xa0 [xe]
? ttm_bo_pipeline_gutting+0x71/0x180 [ttm]
xe_test_dmabuf_move_notify_no_resource+0x182/0x440 [xe]
xe_dma_buf_kunit+0x387/0x580 [xe]
v2: Add Fixes tag and failure info in commit text (Matt Brost)
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Assisted-by: GitHub-Copilot:claude-opus-4.8
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Link: https://patch.msgid.link/20261012215014.1495677-5-niranjana.vishwanathapura@intel.com
|
|
ath12k_mac_vdev_delete() walks txmgmt_idr with idr_for_each(), and its
callback removes each entry belonging to the interface. Removing the
current entry can invalidate the radix-tree iterator retained by
idr_for_each().
Move the walk into a helper that uses idr_for_each_entry(). It performs a
fresh lookup for every iteration, so each matching entry can be removed
through the locked removal helper without retaining iterator state across
the removal.
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20261003092104.520135-6-yaojiale02@163.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
The pending management TX cleanup walks txmgmt_idr with idr_for_each(),
and its callback removes the current entry. This can invalidate the
radix-tree iterator retained by idr_for_each().
Use idr_for_each_entry() so every iteration starts with a fresh lookup.
Continue to remove each entry under txmgmt_idr_lock before freeing its skb,
preventing concurrent TX completion from finding a stale skb pointer.
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20261003092104.520135-5-yaojiale02@163.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
ath11k_mac_op_remove_interface() walks txmgmt_idr with idr_for_each(),
and its callback removes each entry belonging to the interface. Removing
the current entry can invalidate the radix-tree iterator retained by
idr_for_each().
Move the walk into a helper that uses idr_for_each_entry(). It performs a
fresh lookup for every iteration, so each matching entry can be removed
through the locked removal helper without retaining iterator state across
the removal.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20261003092104.520135-4-yaojiale02@163.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
The pending management TX cleanup walks txmgmt_idr with idr_for_each(),
and its callback removes the current entry. This can invalidate the
radix-tree iterator retained by idr_for_each().
Use idr_for_each_entry() so every iteration starts with a fresh lookup.
Continue to remove each entry under txmgmt_idr_lock before freeing its skb,
preventing concurrent TX completion from finding a stale skb pointer.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20261003092104.520135-3-yaojiale02@163.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
ath10k_htt_flush_tx_queue() walks pending_tx with idr_for_each().
Its callback calls ath10k_txrx_tx_unref(), which removes the current
entry from pending_tx through ath10k_htt_tx_free_msdu_id().
idr_for_each() keeps radix-tree iterator state across the callback.
Removing the current entry can therefore invalidate that state and
make the remaining walk unsafe.
Use idr_for_each_entry(), which starts a fresh lookup after each
callback. The current entry can then be removed safely, while the
following idr_destroy() continues to release the IDR itself.
Fixes: 89d6d83565e9 ("ath10k: use idr api for msdu_ids")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20261003092104.520135-2-yaojiale02@163.com
[changed ath10k_htt_tx_clean_up_pending() signature]
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
Currently, NAPI instances and their associated netdevs allocated for AHB
external IRQ groups are not released when external IRQ configuration
fails. They are also not freed when arch_init() fails after
ath12k_ahb_config_irq() succeeds during probe, or when the driver is
unloaded.
Fix this by adding a common cleanup helper to release the NAPI instances
and associated netdevs. Call it from the external IRQ configuration error
path, probe error path, and driver cleanup path.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Fixes: 6cee30f0da75 ("wifi: ath12k: add AHB driver support for IPQ5332")
Fixes: 614c23e24ee8 ("wifi: ath12k: Support arch-specific DP device allocation")
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20261001045423.493121-1-aaradhana.sahu@oss.qualcomm.com
[renamed label err_free_irq]
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
|
|
The main read / write "buffer" is kzalloc()ed and as such is safe to
directly use for DMA (unlike stack mem). Add the I2C_M_DMA_SAFE flag
to the transfers using these buffers.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Acked-by: Mika Westerberg <westeri@kernel.org>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20260919193642.43058-1-johannes.goede@oss.qualcomm.com
|
|
|
|
Currently, the source clock lookup prefers 32 MHz whenever that rate is
available, regardless of the rate configured by the platform. Before the
switch to looking up the clock index, the driver used the 32 MHz timing
table only if the current source clock rate was 32 MHz, and the 19.2 MHz
table otherwise.
On X1E80100 CRD, this results in switching the source clock from 19.2 MHz
to 32 MHz, which causes intermittent failures when probing the I2C HID
keyboard. These range from corrupted HID descriptors to failed resets
and transfer timeouts, which also affect the touchpad on the same bus.
Restore the original selection policy: use 32 MHz if already selected,
otherwise request 19.2 MHz. Look up the index for the selected rate and
keep the check that rejects higher-frequency multiples. This retains
the dynamic clock index lookup without preferring 32 MHz on platforms
that previously used 19.2 MHz. Report the requested rate if the lookup
fails.
Fixes: cb97bf3d4f91 ("i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL")
Assisted-by: LLM
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Tested-by: Hasty Heat <hastyheat@gmail.com>
Tested-by: Mitchell Augustin <mitchell.augustin@canonical.com>
Reviewed-by: Mitchell Augustin <mitchell.augustin@canonical.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20260928-b4-i2c-qcom-geni-preserve-source-clock-v1-1-9aded7552a76@oss.qualcomm.com
|
|
With RRS Software Visibility, pci_dev_wait() considers a device ready as
soon as reading the Vendor ID doesn't return the RRS value. Devices aren't
required to respond with RRS while they aren't ready, so the read may
return ~0 and pci_dev_wait() stops waiting too early. This was seen with
Intel [8086:0a54] and Samsung [144d:a80c] NVMe SSDs.
Also wait while the Vendor ID reads ~0. A VF's Vendor ID always reads ~0,
so check its Command register instead, as is done without RRS SV.
Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS")
Link: https://lore.kernel.org/r/20250611101442.387378-1-hui.wang@canonical.com
Suggested-by: Lukas Wunner <lukas@wunner.de>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Alexander Gruhlke <gruhlke@mailbox.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20261011190145.23621-3-gruhlke@mailbox.org
|
|
The Samsung 990 PRO [144d:a80c] advertises Immediate Readiness, so
pcie_flr() doesn't wait after FLR, but the drive returns ~0 for up to 7 ms.
Since commit 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring
BARs"), the config restore after FLR is lost, which breaks VFIO passthrough
of the drive. Firmware 8B2QJXD7 responds right after FLR, but older
firmware such as 1B2QJXD7 doesn't, and the firmware version isn't visible
here.
Ignore Immediate Readiness on this device, so pcie_flr() waits.
Fixes: 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs")
Link: https://bbs.archlinux.org/viewtopic.php?id=314833
Link: https://lore.kernel.org/r/20261010160529.27974-1-gruhlke@mailbox.org
Suggested-by: Lukas Wunner <lukas@wunner.de>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Alexander Gruhlke <gruhlke@mailbox.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20261011190145.23621-2-gruhlke@mailbox.org
|
