It is possible that the dm_ima_measure_on_* functions run at the same
time as a table is getting swapped, but before the md->ima.active_table
is updated by dm_ima_measure_on_device_resume(). Instead of using the
current device size, use the size of the active table that is being
measured (assuming there is one), so the information is consistent.
Also, don't allocate a separate string to hold the capactiy. Just
print it directly to the measurement buffer.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
dm-ima: Fail more gracefully in dm_ima_measure_on_*
In all the dm_ima_measure_on_* functions besides
dm_ima_measure_on_table_load(), even if measuring the event fails, it's
still possible to update dm->ima, so that it continues to correctly
track the device state. This means that one measurement failure won't
cause future measurements to record the wrong data.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
a device rename could happen after do_resume() removed the inactive
table that it was swapping to out of the hash cell, but before it was
made the active table. In this case, the table metadata would still
have the old name. Update the swapped table's metadata to avoid this.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
dm-ima: Fix issues with dm_ima_measure_on_device_rename
dm_ima_measure_on_device_rename() can be called on a device before it
ever loads a table, so it needs to handle the case where there is no
table metadata. Also, it was only updating the table_metadata on the
active table. If there was an inactive table when the device was renamed
and that table was later swapped in as the active table, it would
still have the old name. dm_ima_measure_on_device_rename() was also
needlessly allocating new memory for the updated table metadata, instead
of just reusing the existing memory.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
dm-ima: remove new_map from dm_ima_measure_on_device_clear
Now that two processes can't modify md->ima in
dm_ima_measure_on_device_clear() at the same time, there's no need to
track if an inactive table was actually removed. We might as well
clean it up unconditionally, on the off chance that a previous
ima measurement failed and left md->ima.inactive_table behind.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
anc_configure() passed values from drvdata->anc_fir_values[],
drvdata->anc_iir_values[] and drvdata->sid_fir_values[] as register
offset to snd_soc_component_read(). The content of these arrays are user
controllable via the component controls "ANC FIR Coefficients", "ANC
IIR Coefficients" and "Sidetone FIR Coefficients" which I assume are
supposed to hold register values, not register offsets.
Without a datasheet for that component and given that before commit a201aef1a88b ("ASoC: codecs: ab8500: Fix casting of private data") the
arrays overlapped with driver control structures and thus didn't work
properly since 2012, drop that functionality and let someone repair it
who has an actual need for it.
With the core functionally removed several code parts become essentially
unused and are removed, too.
dm-ima: Fix UAF errors and measuring incorrect context
the dm-ima code did not keep the dm_ima_measure_on_* functions from
running at the same time. This could lead to various errors. If two
processes were updating the device state, one could update the state
first, but the other could measure the state first, causing the the
current device state to appear incorrect. If a table load happened while
a device was resuming, the IMA measurement could report the wrong table
being active. And if two dm_ima_measure_on_* functions ran at the same
time, one of them could free data that the other was accessing, causing
a crash.
All the core dm functions that call a dm_ima_measure_on_* function
update the device state they want to measure under the _hash_lock,
except for do_resume(). But holding the _hash_lock is not a good way to
synchronize these functions. It's a global mutex, that is needed in many
dm operations, and the dm_ima_measure_* functions can sleep, blocking
any dm operation on any device that needs the _hash_lock.
To serialize and order the IMA measurement functions, the
dm_ima_measurements now has two counters, update_idx and measure_idx.
update_idx is incremented while holding the _hash_lock and saved, along
with the device name and uuid, in a dm_ima_context struct. Once the
_hash_lock is dropped, the dm_ima_measure_* function is called. It waits
until measure_idx matches the saved value of update_idx, ensuring that
the updates and measurements happen in the same order if there are
multiple processes changing the device at the same time. Then it
measures the device, updates measure_idx, and wakes up any other
process waiting to do a measurement. This makes sure that the
measurements are serialized and done in the order that the _hash_lock
was acquired in. But they only block other measurements for the same
device, which are unlikely to happen at the same time.
do_resume() is trickier, because it removes the inactive table while
holding the _hash_lock, but doesn't hold it while updating md->map. To
make sure it is also ordered, the IMA code grabs the _hash_lock after
md->map is updated. Then it makes sure that the device isn't being
removed and that another do_resume() hasn't already changed the active
table again, and serializes like the other functions do.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
dm-ima: don't copy the active table to the inactive table
If an inactive table was cleared, dm_ima_measure_on_table_clear() was
copying the ima.active_table to ima.inactive_table. This is not what
device-mapper does, and it makes the IMA measurements show an inactive
table when there isn't one. Also, once this is removed, the code no
longer needs to keep checking if the active and the inactive table point
to the same memory.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
When it ran out of space for adding more targets to the ima_buf,
dm_ima_measure_on_table_load() would measure the dm device early, and
then add the rest of the targets and measure it again.
last_target_measured was intended to flag the last target measured so
that the device wouldn't get remeasured, if no new targets were added
after the early measurement. But the way to code works, the dm device
will never be measured early unless there is another target to add to
the ima_buf. Instead, if there is only one more target to add, that
target was getting added to the ima_buf, but it wasn't getting
remeasured, because last_target_measured was set. Since
dm_ima_measure_on_table_load() only measures a device early when there
are more targets to add, the final measurement must always happen, and
last_target_measured is unneeded.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
There's no point in saving the string length of DM_IMA_VERSION_STR. It's
a constant, so the compiler will precompute it. dm_create() will already
zero out the rest of dm->ima.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
returning DM_MAPIO_REQUEUE from the target map() function only requeues
the bio during noflush suspends. During regular operations or during
flushing suspends, it fails the bio. Failing the bio during flushing
suspends is the correct behavior here. We cannot handle the bio, and we
cannot suspends while it is outstanding. But during normal operations,
we should not push the bio back to dm. Instead, wait for the reshape
to be resumed.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
David Carlier [Sun, 5 Apr 2026 15:47:13 +0000 (16:47 +0100)]
dm vdo: use get_random_u32() where appropriate
Use the typed random integer helpers instead of
get_random_bytes() when filling a single integer variable.
The helpers return the value directly, require no pointer
or size argument, and better express intent.
Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Set PM ops for the vesadrm driver. Suspend and resume the DRM state
on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Set PM ops for the simpledrm driver. Suspend and resume the DRM
state on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Set PM ops for the ofdrm driver. Suspend and resume the DRM state
on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Set PM ops for the efidrm driver. Suspend and resume the DRM state
on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Set PM ops for the corebootdrm driver. Suspend and resume the DRM
state on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Fold the '+' check in the single-underscore-prefixed version
_kstrtoull() and remove the function. The arch/x86/boot/ namespace
prefixes everything copied from kernel proper with "boot_" so that
namespace clashes can be avoided.
x86/boot/compressed: Use boot_kstrtoul() for hugepages= parsing
Replace simple_strtoull() with boot_kstrtoul() for parsing the hugepages= boot
parameter.
Unlike simple_strtoull(), boot_kstrtoul() performs strict validation and
returns an error on invalid inputs instead of silently accepting partial
input. Use boot_kstrtoul() to reject and warn about invalid hugepages= values.
boot_kstrtoul() also converts the input directly to an unsigned long and
avoids implicit casting as max_gb_huge_pages *is* an unsigned long.
Add support for the PLLDSI{0,1} clocks in the r9a09g047 CPG driver.
Introduce CLK_PLLDSI{0,1} also, introduce the
rzg3e_cpg_pll_dsi{0,1}_limits structures to describe the frequency
constraints specific to the RZ/G3E SoC.
On Renesas RZ/G3E:
- PLLDSI0 maximum output frequency: 1218 MHz
- PLLDSI1 maximum output frequency: 609 MHz
These limits are enforced through the newly added
RZG3E_CPG_PLL_DSI{0,1}_LIMITS().
Add PLLDSI clk mux support to select PLLDSI clock from different clock
sources.
Introduce the DEF_PLLDSI_SMUX() macro to define these muxes and register
them in the clock driver.
Extend the determine_rate callback to calculate and propagate PLL
parameters via rzv2h_get_pll_dtable_pars() when LVDS output is selected,
using a new helper function rzv2h_cpg_plldsi_smux_lvds_determine_rate().
The CLK_SMUX2_DSI{0,1}_CLK clock multiplexers select between two paths
with different duty cycles:
Implement rzv2h_cpg_plldsi_smux_{get,set}_duty_cycle clock operations to
allow the DRM driver to query and configure the appropriate clock path
based on the required output duty cycle.
Replace vmwgfx's vblank timer with DRM's common implementation. The
timer handling is almost identical with a few additional bug fixes in
the common code.
Replace most of vmwgfx's vmw_vkms_get_vblank_timestamp() with the
shared helper drm_crtc_vblank_get_vblank_timeout(). The common helper
also works in the presence of delayed vblank timeouts that modify the
vblank counter concurrently.
Set the timeout handler to vmw_vkms_handle_vblank_timeout(). In addition
to handling vblank events, this function also controls CRC generation.
Remove all the hrtimer-related code from vmwgfx. DRM vblank timers
provides this.
v2:
- only cancel vblank timer in CRTC cleanup if vkms_enabled (Zack)
drm/vmwgfx: Move vblank handling into separate helper
Decouple vblank handling from the underlying hrtimer. This will be
helpful for replacing vmwgfx's vblank timer with DRM's common
implementation.
The new helper vmw_vkms_handle_vblank_timeout() can later be used as
callback for DRM's handle_vblank call as-is. The helper also keeps the
current semantics for restarting the timer. It returns true to restart
the next vblank timeout even if it could not acquire vmwgfx's vblank
lock.
The remaining code in vmw_vkms_vblank_simulate() will be replaced by
the DRM implementation in a later patch.
v2:
- clarify return-value semantics in commit message (Zack)
drm/vmwgfx: Determine lock-waiting timeout from vblank state
Use the calculated duration of a frame as stored in the vblank state
for the lock-waiting timeout. Decouples the waiting from the details
of the vblank implementation. Both values should be equal.
This will be helpful for replacing vmwgfx's vblank timer with DRM's
common implementation.
Tristan Madani [Fri, 1 May 2026 11:02:03 +0000 (11:02 +0000)]
gfs2: fix use-after-free in gfs2_qd_dealloc
gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(),
accesses the superblock object sdp through qd->qd_sbd after freeing qd.
It does so to decrement sd_quota_count and wake up sd_kill_wait.
However, by the time the RCU callback runs, gfs2_put_super() may have
already freed sdp via free_sbd(). This can happen when
gfs2_quota_cleanup() is called during unmount: it disposes of quota
objects via call_rcu() and then waits on sd_kill_wait with a 60-second
timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers
additional qd_put() calls that schedule more RCU callbacks after the
wait completes, gfs2_put_super() will proceed to free the superblock
while RCU callbacks referencing it are still pending.
Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure
all pending RCU callbacks (including gfs2_qd_dealloc) have completed
before the superblock is freed.
Ian Dannapel [Thu, 16 Apr 2026 14:42:36 +0000 (16:42 +0200)]
fpga-mgr: Add Efinix SPI programming driver
Add a new driver for loading binary firmware to configuration
RAM using "SPI passive mode" on Efinix FPGAs.
Efinix passive SPI configuration requires chip select to remain asserted
from reset until the complete bitstream and trailing idle clocks have
been transferred, so the driver keeps CS active with cs_change and locks
the SPI bus for the duration of configuration.
Thorsten Blum [Sun, 3 May 2026 10:11:02 +0000 (12:11 +0200)]
ALSA: jack: use scnprintf to improve parse_mask_bits
Use the return value of scnprintf() to keep track of the current string
length and also replace strlcat() with scnprintf(). Return the string
length directly instead of calling strlen(buf).
Phil Pemberton [Thu, 9 Apr 2026 12:20:16 +0000 (13:20 +0100)]
fpga: ts73xx-fpga: add OF match table for device tree probing
The ts73xx-fpga driver currently only matches by platform device name,
which prevents it from being probed when the device is described in a
device tree. Add an of_device_id table so the driver can match against
the "technologic,ts7300-fpga" compatible string.
The TS-7350 and TS-7390 use different FPGAs with a different programming
interface, so while the driver is named "ts73xx-fpga", it doesn't apply
to them.
Phil Pemberton [Thu, 9 Apr 2026 12:20:15 +0000 (13:20 +0100)]
dt-bindings: fpga: Add Technologic Systems TS-7300 FPGA Manager
Add device tree binding documentation for the Altera Cyclone II FPGA
found on Technologic Systems (now EmbeddedTS) TS-7300 boards, programmed
via the memory-mapped interface in the CPLD.
Signed-off-by: Phil Pemberton <philpem@philpem.me.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260409122016.3940462-2-philpem@philpem.me.uk Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
Cássio Gabriel [Fri, 1 May 2026 17:45:14 +0000 (14:45 -0300)]
ALSA: pcmtest: Return -EFAULT on pattern read copy failure
pattern_write() reports -EFAULT when copy_from_user() fails, but
pattern_read() converts copy_to_user() failures into a zero-length read.
That makes a userspace buffer fault look like EOF instead of reporting the
actual error.
Return -EFAULT from pattern_read() when copying the pattern data to
userspace fails, and update the file offset only after a successful copy.
Weiming Shi [Tue, 14 Apr 2026 17:23:39 +0000 (01:23 +0800)]
i2c: stub: Reject I2C block transfers with invalid length
The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]
as the transfer length. The existing check only clamps it to avoid
overrunning the chip->words[256] register array, but does not validate
it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union
i2c_smbus_data.block buffer (34 bytes total). The driver is a
development/test tool (CONFIG_I2C_STUB=m, not built by default)
that must be loaded with a chip_addr= parameter.
A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl
with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing
stub_xfer() to read or write past the end of the union
i2c_smbus_data.block buffer:
BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)
Read of size 1 at addr ffff88800abcfd92 by task exploit/81
Call Trace:
<TASK>
stub_xfer (drivers/i2c/i2c-stub.c:223)
__i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)
i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)
i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)
i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)
__x64_sys_ioctl (fs/ioctl.c:583)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
</TASK>
The bug exists because i2c-stub implements .smbus_xfer directly,
bypassing the I2C_SMBUS_BLOCK_MAX validation in
i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same
function correctly validates against I2C_SMBUS_BLOCK_MAX, but the
I2C_SMBUS_I2C_BLOCK_DATA case does not.
Fix by rejecting transfers with data->block[0] == 0 or
data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with
both the I2C_SMBUS_BLOCK_DATA case in the same function and the
I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().
Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
ALSA: Consistently define pci_device_ids using named initializers
... and PCI device helpers.
The various struct pci_device_id arrays were initialized mostly by list
expressions, some of them using the PCI_DEVICE macros. This isn't easily
readable if you're not into PCI. Using named initializers is more
explicit and thus easier to parse. Also use PCI_DEVICE* helper macros to
assign .vendor, .device, .subvendor and .subdevice where appropriate and
skip explicit assignments of 0 (which the compiler takes care of).
The secret plan is to make struct pci_device_id::driver_data an
anonymous union (similar to
https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
and that requires named initializers. But it's also a nice cleanup on
its own.
This change doesn't introduce changes to the compiled pci_device_id
array. Tested on x86 and arm64.
Ivan Hu [Thu, 30 Apr 2026 07:41:07 +0000 (15:41 +0800)]
x86/efi: Fix graceful fault handling after FPU softirq changes
Since commit d02198550423 ("x86/fpu: Improve crypto performance by
making kernel-mode FPU reliably usable in softirqs"), kernel_fpu_begin()
calls fpregs_lock() which uses local_bh_disable() instead of the
previous preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count
during the entire EFI runtime service call, causing in_interrupt() to
return true in normal task context.
The graceful page fault handler efi_crash_gracefully_on_page_fault()
uses in_interrupt() to bail out for faults in real interrupt context.
With SOFTIRQ_OFFSET now set, the handler always bails out, leaving EFI
firmware page faults unhandled. This escalates to die() which also sees
in_interrupt() as true and calls panic("Fatal exception in interrupt"),
resulting in a hard system freeze. On systems with buggy firmware that
triggers page faults during EFI runtime calls (e.g., accessing unmapped
memory in GetTime()), this causes an unrecoverable hang instead of the
expected graceful EFI_ABORTED recovery.
Fix by replacing in_interrupt() with !in_task(). This preserves the
original intent of bailing for interrupts or NMI faults, while no longer
falsely triggering from the FPU code path's local_bh_disable().
Fixes: d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") Cc: <stable@vger.kernel.org> Signed-off-by: Ivan Hu <ivan.hu@canonical.com>
[ardb: Sashiko spotted that using 'in_hardirq() || in_nmi()' leaves a
window where a softirq may be taken before fpregs_lock() is
called, but after efi_rts_work.efi_rts_id has been assigned,
and any page faults occurring in that window will then be
misidentified as having been caused by the firmware. Instead,
use !in_task(), which incorporates in_serving_softirq(). ] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
drm/bridge: ti-sn65dsi83: add test pattern generation support
Generation of a test pattern output is a useful tool for panel bringup and
debugging, and very simple to support with this chip.
The value of REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW needs to be divided by two
for the test pattern to work in dual LVDS mode. While not clearly stated in
the datasheet, this is needed according to the DSI Tuner [0] output. And
some dual-LVDS panels refuse to show any picture without this division by
two.
Wolfram Sang [Thu, 2 Apr 2026 11:27:06 +0000 (13:27 +0200)]
soc: renesas: Add Renesas R-Car MFIS driver
Renesas R-Car MFIS offers multiple features but most importantly
mailboxes and hwspinlocks. Because they share a common register space
and a common register unprotection mechanism, a single driver was chosen
to handle all dependencies. (MFD and auxiliary bus have been tried as
well, but they failed because of circular dependencies.)
In this first step, the driver implements common register access and a
mailbox controller. hwspinlock support will be added incrementally, once
the subsystem allows out-of-directory drivers.
Hongling Zeng [Sun, 3 May 2026 04:17:44 +0000 (12:17 +0800)]
parisc: Fix IRQ leak in LASI driver
When request_irq() succeeds but gsc_common_setup() fails later,
the IRQ is never released. Fix this by adding proper error handling
with goto labels to ensure resources are released in LIFO order.
Detected by Smatch:
drivers/parisc/lasi.c:216 lasi_init_chip() warn: 'lasi->gsc_irq.irq'
from request_irq() not released on lines: 207.
Wolfram Sang [Thu, 2 Apr 2026 11:27:05 +0000 (13:27 +0200)]
dt-bindings: soc: renesas: Document MFIS IP core
Document the Renesas Multifunctional Interface (MFIS) as found on the
Renesas R-Car X5H (r8a78000) SoC. MFIS includes features like Mailbox/HW
Spinlock/Product Register/Error Injection/Error Detection and the likes.
Family-compatible values are not introduced here because MFIS is usually
very different per SoC.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260402112709.13002-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Mingyu Wang [Mon, 27 Apr 2026 02:57:45 +0000 (10:57 +0800)]
i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl
While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong
timeout value` warning was observed, accompanied by SMBus controller
state machine corruption.
The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of
10 ms. The user argument is checked against INT_MAX, but it is
subsequently multiplied by 10 before being passed to msecs_to_jiffies().
A malicious user can pass a large value (e.g., 429496729) that passes
the `arg > INT_MAX` check but overflows when multiplied by 10. This
results in a truncated 32-bit unsigned value that bypasses the
internal `(int)m < 0` check in `msecs_to_jiffies()`.
The truncated value is then assigned to `client->adapter->timeout`
(a signed 32-bit int), which is reinterpreted as a negative number.
When passed to wait_for_completion_timeout(), this negative value
undergoes sign extension to a 64-bit unsigned long, triggering the
`schedule_timeout` warning and causing premature returns. This leaves
the SMBus state machine in an unrecoverable state, constituting a
local Denial of Service (DoS).
Fix this by bounding the user argument to `INT_MAX / 10`.
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
[wsa: move the comment as well] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Jani Nikula [Thu, 30 Apr 2026 08:28:52 +0000 (11:28 +0300)]
drm/i915/display: move display funcs under modeset sub-struct
Move generic crtc-ish modeset related functions under a new modeset
sub-struct of struct intel_display. Rename struct intel_display_funcs to
intel_modeset_funcs to make it a little bit more specific. Remove the
funcs sub-struct.
The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.
x86/entry: Zap the #VC entry user and kernel macros
Drop the separate kernel and user macros in favor of calling a single #VC
C handler which multiplexes between the kernel and user #VC entry points
by looking at CS's RPL.
Zap unused DEFINE_IDTENTRY_VC while at it.
There should be no functionality change resulting from this - just code
simplification.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Nikunj A. Dadhania <nikunj@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Joerg Roedel <joerg.roedel@amd.com> Tested-by: Nikunj A. Dadhania <nikunj@amd.com> Link: https://patch.msgid.link/20260420164352.32129-1-bp@kernel.org
i2c: acpi: Add ELAN0678 to i2c_acpi_force_100khz_device_ids
The ELAN0678 touchpad (04F3:3195) found in the Lenovo ThinkPad X13
exhibits excessive smoothing when the I2C bus runs at 400KHz, making
the touchpad feel sluggish when plugged into AC power. This is the
same issue previously fixed for ELAN06FA.
The device's ACPI table (Lenovo TP-R22) specifies 0x00061A80 (400KHz)
for the I2cSerialBusV2 descriptor. Forcing the bus to 100KHz eliminates
the sluggish behavior.
Signed-off-by: Niels Franke <nielsfranke@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[wsa: kept the sorting] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Rajat Gupta [Mon, 4 May 2026 03:51:10 +0000 (20:51 -0700)]
fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free
dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages
to userspace but sets no vm_ops on the VMA. This means the kernel cannot
track active mmaps. When dlfb_realloc_framebuffer() replaces the backing
buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated.
On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages
while userspace PTEs still reference them, resulting in a use-after-free:
the process retains read/write access to freed kernel pages.
Add vm_operations_struct with open/close callbacks that maintain an
atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(),
check mmap_count and return -EBUSY if the buffer is currently mapped,
preventing buffer replacement while userspace holds stale PTEs.
Tested with PoC using dummy_hcd + raw_gadget USB device emulation.
Janne Grunau [Fri, 20 Mar 2026 12:23:24 +0000 (13:23 +0100)]
dt-bindings: i2c: apple,i2c: Add t8122 compatible
The i2c block on the Apple silicon t8122 (M3) SoC is compatible with the
existing driver. Add "apple,t8122-i2c" as SoC specific compatible under
"apple,t8103-i2c" used by the deriver.
Signed-off-by: Janne Grunau <j@jannau.net> Acked-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Wrap the conditional operation in parentheses to enforce the
correct evaluation order.
Fixes: 93eee2a49c1b ("iommu/amd: Refactor logic to program the host page table in DTE") Signed-off-by: Weinan Liu <wnliu@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Dave Airlie [Mon, 4 May 2026 08:20:49 +0000 (18:20 +1000)]
Merge tag 'drm-xe-next-2026-04-30' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next
UAPI Changes:
- Debugfs multi-LRC engine info (Xin Wang, 2 commits)
Expose multi-LRC engine classes in the debugfs engine info output
and improve the output readability.
- drm/drm_ras: Add clear-error-counter netlink command to drm_ras
Cross-subsystem Changes:
Core Changes:
- drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges
- drm/i915/display: switch to including common step file directly
Driver Changes:
- Engine initialization cleanup (Matt Roper, 10 commits)
Clean up engine initialization code inherited from i915 by moving
hardware programming (CCS enablement, HWSTAM, GFX_MODE, BLIT_CCTL,
STOP_RING) into the RTP infrastructure. This makes the programming
visible and verifiable via debugfs, and applies consistently across
both normal and execlist init paths. Also fixes the name/definition
of GFX_MODE, marks BCS engines as belonging to the GT forcewake
domain, and drops the now-unused xe_hw_engine_mmio_write32() helper.
- PF fair scheduling auto-provisioning (Michal Wajdeczko, 13 commits)
Fix several corner cases in SR-IOV PF scheduling policy provisioning,
then auto-provision PF and all VFs with 16ms execution-quantum and
preemption-timeout defaults. This prevents a VF from monopolizing
the GPU by submitting workloads without gaps, without requiring the
user to configure sysfs manually.
- System Controller support for CRI/Xe3p (Anoop Vijay + Raag Jadav, 10 commits)
Add xe_sysctrl infrastructure for communicating with the System
Controller firmware entity on CRI/Xe3p discrete GPU platforms via a
mailbox interface. Includes type definitions, register definitions,
mailbox communication, initialization, power management, interrupt
handling, and event dispatch. Builds on this to add initial RAS
correctable error handling, using sysctrl interrupts to receive
threshold-crossed events.
- PXP state machine fixes (Daniele Ceraolo Spurio, 4 commits)
Fix PXP state machine handling: reject PXP sessions on PTL platforms
with older GSC firmware that does not support it, fix the restart
flag not being cleared after jumping back in pxp_start, remove
incorrect handling of an impossible state during suspend, and clean
up termination status on failure.
- Reset/wedge/unload corner case fixes (Zhanjun Dong + Matthew Brost, 5 commits)
Fix memory leaks and fence signal failures that occurred during GPU
reset, device wedging, and driver unload by forcefully tearing down
remaining exec queues in GuC submit fini, always killing queues in
pause/abort, and triggering queue cleanup when not in wedged mode 2.
Also ensures GuC CT state transitions via STOP before DISABLED.
- Wedge path memory allocation fixes (Matthew Brost, 3 commits)
Avoid GFP_KERNEL allocations in xe_device_declare_wedged(), which
runs in the DMA-fence signaling path. Also drops the
guc_submit_wedged_fini devm registration from xe_guc_submit_wedge()
to clean up the wedge shutdown sequence.
- PAT type cleanup and invalid index hardening (Xin Wang, 3 commits)
Standardize pat_index fields to u16 across the driver, default
XE_CACHE_NONE_COMPRESSION to XE_PAT_INVALID_IDX (matching
WB_COMPRESSION), and introduce xe_cache_pat_idx() — a macro helper
that validates cache_mode bounds and asserts on invalid PAT indices
before returning the index.
- Reject unsafe PAT indices for CPU cached memory (Jia Yao, 2 commits)
Reject incoherent (coh_none) PAT indices for CPU cached memory in
both the madvise ioctl and vm_bind with CPU_ADDR_MIRROR flag, closing
a security gap where the GPU could bypass CPU caches and observe
stale or sensitive data.
- OA improvements for CRI device memory (Ashutosh Dixit, 3 commits)
Move OA buffer access to the xe_map layer to support both system and
device memory (required for CRI), switch OA buffer mmap to use
drm_gem_mmap_obj, and implement workaround Wa_14026633728.
- xe_drm.h documentation fixes (Shuicheng Lin, 6 commits)
Fix multiple documentation issues in the xe_drm.h UAPI header:
typos, spelling errors, grammar, wrong names and references,
kernel-doc cross-reference syntax, and broken code examples.
- kernel-doc syntax fixes in xe headers (Shuicheng Lin, 4 commits)
Fix kernel-doc syntax issues across xe header files: missing '@'
prefixes on member tags, stale/mismatched member tags, comment
syntax errors, and type/parameter name mismatches in references.
- Buffer object and DMA-buf resource leak fixes (Shuicheng Lin, 4 commits)
Fix resource leaks on error paths: DMA-buf attachment leak in
xe_gem_prime_import(), BO leak in xe_dma_buf_init_obj() on
allocation failure, and BO leaks in xe_bo_init_locked() on GGTT
flag validation and unaligned size validation failures.
- Include guard cleanup (Shuicheng Lin, 5 commits)
Fix and standardize include guards across xe header files: normalize
double-underscore guards to single, add missing leading/trailing
underscores, add missing _H suffixes, and add guards to previously
unprotected headers.
- VF CCS memory pool (Satyanarayana K V P, 2 commits)
Switch VF CCS read/write operations from the DRM sub-allocator to
DRM mm, fixing allocation failures in fence-disabled mode where
the sub-allocator's hole cursor assumption breaks. Also introduces
a general BO-backed memory pool with shadow support using drm_mm.
- i915/xe step definition unification (Jani Nikula, 3 commits)
Complete the migration to the shared intel_step header: switch xe
from its own xe_step enum to the shared intel_step naming and
definitions, and update i915 display code to include the common
step header directly.
- Xe3p GT tuning fixes (3 commits)
Three Xe3p GT tuning corrections: fix the register offset for
GAMSTLB_CTRL, stop applying the CCCHKNREG1 tuning from Xe3p onward
(no longer needed), and mark ROW_CHICKEN5 as a masked register.
- Forcewake cleanup in GT and GuC PC (Raag Jadav, 3 commits)
Drop a redundant forcewake reference in xe_gt, reorder forcewake
usage in xe_guc_pc_fini_hw() to avoid a redundant hold, and convert
xe_guc_pc_stop() to void since it can no longer fail.
- SVM garbage collector fix on close (Matthew Brost, 2 commits)
Disable the SVM garbage collector work item when an SVM is closed
to prevent use-after-free when the GC fires after the SVM is freed.
- Admin-only PF mode (Satyanarayana K V P, 2 commits)
Derive an "admin-only PF" mode flag from xe_device state instead of
using a local flag, and restrict device query responses when running
in admin-only PF mode to avoid exposing internal state.
- Enable hwmon energy attributes and accepted power limit for CRI (2 commits)
Enable energy consumption hwmon attributes for the CRI platform and
add support for reading the accepted (sustained) power limit via
hwmon.
Marek Vasut [Sat, 2 May 2026 15:31:54 +0000 (17:31 +0200)]
i2c: stm32f7: reinit_completion() per transfer not per msg
Currently, the driver may repeatedly call reinit_completion() during
transfer which contains multiple messages, while another thread is
waiting for the completion.
This happens during transfer with more than 1 message, invoked via
stm32f7_i2c_xfer_core() -> stm32f7_i2c_xfer_msg(). After invoking the
stm32f7_i2c_xfer_msg() to start transfer, stm32f7_i2c_xfer_core()
calls wait_for_completion_timeout() to wait for completion of the
transfer of all messages. When the first message transfer completes,
the hard IRQ handler triggers, and detects transfer completion, which
leads to stm32f7_i2c_isr_event_thread() IRQ thread being started. The
stm32f7_i2c_isr_event_thread() calls stm32f7_i2c_xfer_msg() in case
there are more messages.
Without this change, the second and later stm32f7_i2c_xfer_msg() would
call reinit_completion() on the completion which is still being waited
for in stm32f7_i2c_xfer_core(). Fix this by moving the reinit_completion()
into stm32f7_i2c_xfer_core(), together with wait_for_completion_timeout().
Since stm32f7_i2c_xfer_core() now waits for completion of the entire
transfer, increase the default timeout. This fixes sporadic transfer
timeouts on STM32MP25xx during kernel boot.
Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver") Signed-off-by: Marek Vasut <marex@nabladev.com>
[wsa: reworded commit subject] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Ronald Claveau [Fri, 24 Apr 2026 14:17:33 +0000 (16:17 +0200)]
dt-bindings: i2c: amlogic: Add compatible for T7 SOC
Add the T7 SOC compatible which fallback to AXG compatible.
Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Marco Crivellari [Thu, 30 Apr 2026 09:08:10 +0000 (11:08 +0200)]
i2c: testunit: Replace system_long_wq with system_dfl_long_wq
Currently the code enqueue work items using {queue|mod}_delayed_work(),
using system_long_wq. This workqueue should be used when long works are
expected, but it is a per-cpu workqueue.
This is important because queue_delayed_work() queue the work using:
queue_delayed_work_on(WORK_CPU_UNBOUND, ...);
Note that WORK_CPU_UNBOUND = NR_CPUS.
This would end up calling __queue_delayed_work() that does:
if (housekeeping_enabled(HK_TYPE_TIMER)) {
// [....]
} else {
if (likely(cpu == WORK_CPU_UNBOUND))
add_timer_global(timer);
else
add_timer_on(timer, cpu);
}
So when cpu == WORK_CPU_UNBOUND the timer is global and is
not using a specific CPU. Later, when __queue_work() is called:
if (req_cpu == WORK_CPU_UNBOUND) {
if (wq->flags & WQ_UNBOUND)
cpu = wq_select_unbound_cpu(raw_smp_processor_id());
else
cpu = raw_smp_processor_id();
}
Because the wq is not unbound, it takes the CPU where the timer
fired and enqueue the work on that CPU.
The consequence of all of this is that the work can run anywhere,
depending on where the timer fired.
Recently, a new unbound workqueue specific for long running work has
been added:
c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works")
So change system_long_wq with system_dfl_long_wq so that the work may
benefit from scheduler task placement.
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
[wsa: remove FIXME as well] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
gpiolib: move legacy interface into linux/gpio/legacy.h
Split the old contents from gpio.h for clarity. Ideally any driver
that still includes linux/gpio.h can now be ported over to use
either linux/gpio/legacy.h or linux/gpio/consumer.h, with the
original file getting removed once that is complete.
Samuel Holland [Mon, 6 Apr 2026 22:14:40 +0000 (01:14 +0300)]
media: cedrus: Fix failure to clean up hardware on probe failure
If V4L2 device fails to register, then SRAM still be claimed and as a
result driver will not be able to probe again.
cedrus 1c0e000.video-codec: Failed to claim SRAM
cedrus 1c0e000.video-codec: Failed to probe hardware
cedrus 1c0e000.video-codec: probe with driver cedrus failed with error -16
cedrus_hw_remove undoes everything that was previously done by
cedrus_hw_probe, such as disabling runtime power management and
releasing the claimed SRAM and reserved memory region.
Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Acked-by: Paul Kocialkowski <paulk@sys-base.io> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Samuel Holland [Mon, 6 Apr 2026 22:14:02 +0000 (01:14 +0300)]
media: cedrus: Fix missing cleanup in error path
According to the documentation struct v4l2_fh has to be cleaned up with
v4l2_fh_exit() before being freed. [1]
Currently there is no actual bug here, when v4l2_fh_exit() isn't called.
v4l2_fh_exit() in this case only destroys internal mutex. But it may
change in the future, when v4l2_fh_init/v4l2_fh_exit will be enhanced.
media: chips-media: wave5: Fix Reports from Kernel Lock Validator
handle_dynamic_resolution change requires that the state_lock be acquired
based on the lockdep_assert_held. However, the
handle_dynamic_resolution_change call in initialize_sequence does not
properly obtain the lock before calling.
Since the v4l2_ctrl_find and s_ctrl can sleep, they should not be called
while a lock is already held. Store off the fbc_buf_count then properly
update control once lock has been freed.
Signed-off-by: Brandon Brnich <b-brnich@ti.com> Tested-by: Jackson Lee <jackson.lee@chipsnmedia.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: chips-media: wave5: Release m2m_ctx after Instance Removed from List
Possible use after free if IRQ thread manages to obtain spinlock between
m2m_ctx release and wave5_release function removing stream instance from
list of active instances. The IRQ thread looks for the m2m_ctx which is
freed so null pointer dereference occurs.
Signed-off-by: Brandon Brnich <b-brnich@ti.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Tested-by: Jackson Lee <jackson.lee@chipsnmedia.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: rkvdec: Introduce a global bitwriter helper
The use of structures with bitfields is good when the values are
somewhat aligned.
More mis-alignement means that compilers need to do more gymnastics
to edit the fields values.
Some cases have been reported with CLang on specific architectures
like armhf and hexagon, where the compiler would allocate a bigger
local stack than needed or even completely freeze during compilation.
Some fixes have been provided to ease the issues, but the real fix
here is to use a bitwriter instead of heavily unaligned bitfields.
This is a preparation commit to provide a global bitwriter interface
for the whole driver.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: verisilicon: Export only needed pixels formats
Some pixel formats can only be produced if the decoder outputs
reference pictures directly. In some cases, such as AV1 film-grain,
the use of the post-processor is strictly required. In this case,
only enumerate the post-processor supported formats. The exception is
when V4L2_FMTDESC_FLAG_ENUM_ALL is set, in this case, we enumerate
everything regardless of the state.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Fixes: bcd4f091cf1e ("media: verisilicon: Use V4L2_FMTDESC_FLAG_ENUM_ALL flag") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Revert commit d98c24617a83 ("wifi: cw1200: Fix locking in error paths")
because it introduces a locking bug instead of fixing a locking bug.
cw1200_wow_resume() unlocks priv->conf_mutex. Hence, adding
mutex_unlock(&priv->conf_mutex) just after cw1200_wow_resume() is wrong.
Reported-by: Ben Hutchings <ben@decadent.org.uk> Closes: https://lore.kernel.org/all/408661f69f263266b028713e1412ba36d457e63d.camel@decadent.org.uk/ Fixes: d98c24617a83 ("wifi: cw1200: Fix locking in error paths") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260430174418.1845431-1-bvanassche@acm.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
drm/bridge: analogix_dp: Extract error pointer from correct variable
In devm_drm_panel_bridge_add() error path the pointer error should be
extracted from dp->plat_data->next_bridge but instead it is extracted
from bridge, which is a valid pointer and not part of this error path.
Extract error pointer from correct variable.
Detected by Smatch:
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1489 analogix_dp_bind()
warn: passing a valid pointer to 'PTR_ERR'
projects / thirdparty / kernel / stable.git / log
