The VAR-SOM-MX8MN module does not provide an onboard USB connector.
The complete USB OTG description, including the Type-C role switch
configuration, is already provided by the Symphony carrier board device
tree. Remove the duplicate USB OTG node from the SOM dtsi to avoid
describing the same hardware in two places.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The VAR-SOM-MX8MN currently integrates the NXP IW61x wireless module,
providing WiFi over SDIO and Bluetooth over UART.
Move the wireless module configuration out of the base
imx8mn-var-som.dtsi and provide dedicated variant includes.
The IW61x configuration is moved to imx8mn-var-som-wifi-bt-iw61x.dtsi
and used by the Symphony evaluation board device tree.
A separate imx8mn-var-som-wifi-brcm-legacy.dtsi include is added to keep
the configuration for the legacy Broadcom SDIO WiFi module used on
earlier SOM revisions.
To preserve compatibility with older SOM revisions, add a separate
imx8mn-var-som-symphony-legacy.dtb, which disables the IW61x setup and
applies the Broadcom-specific configuration.
The Broadcom-based SOM revision is no longer in production, but support
is kept for existing users.
This keeps the VAR-SOM-MX8MN support aligned with the existing
VAR-SOM-MX8MM implementation.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Add support for the Microchip MCP251xFD CAN-FD controller connected
to the SPI bus on the i.MX8MN VAR-SOM.
The controller uses a 40 MHz external oscillator and requires an
interrupt line and a dedicated RX interrupt GPIO.
Add the fixed clock, the MCP251xFD device node with the required
properties, and the corresponding pinctrl configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The VAR-SOM-MX8MN can integrate the WM8904, a high-performance
ultra-low-power stereo codec optimized for portable audio applications.
Add the WM8904 device to the appropriate I2C bus, enable the SAI
peripheral, and introduce the sound node to expose the sound card to the
system.
Add I2C3 recovery gpio properties.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Update the FEC Ethernet controller on the i.MX8MN VAR-SOM to match the
latest SOM hardware revision using the integrated MaxLinear MXL86110 PHY.
Add the PHY VDDIO supply regulator and adjust reset timings.
The PHY LED signals originate on the SOM, but the actual LEDs are part
of the carrier implementation (RJ45 connector). Move the LED
configuration to the Symphony carrier device tree, matching the
evaluation board LED wiring.
Wake-on-LAN via magic packet is not supported at the VAR-SOM level and
is therefore not enabled in the SOM device tree nor in the official
evaluation carrier board configuration (symphony).
Designs requiring WoL support may enable it in their own carrier-specific
device trees if properly integrated at the hardware level.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reformat the fsl,pins tables in the i.MX8MN VAR-SOM device tree to use
consistent column alignment across all pinctrl groups.
Align the entries to match the formatting already used in the
pinctrl_fec1 group, which contains the longest pin definitions,
for improved readability and consistency.
No functional changes intended.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The VAR-SOM-MX8MN module does not provide an onboard SD card slot.
USDHC2 is routed to the SD card slot on the carrier boards.
Move the USDHC2 node and pinctrl configuration from the SOM device tree
to imx8mn-var-som-symphony.dts and imx8mn-rve-gateway.dts, keeping the
SOM dtsi limited to hardware present on the module itself.
Add the required off-on-delay-us property for the USDHC2 regulator on
the Symphony carrier board.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The VAR-SOM-MX8MN module does not provide an onboard debug console.
UART4 is routed and exposed only on the Symphony carrier board, while
custom carrier designs may choose to expose a different UART.
Move the UART4 node from the SOM device tree to the
imx8mn-var-som-symphony.dts, keeping the SOM dtsi limited to hardware
present on the module itself.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Double the fractional part of the horizontal scale factor
for the purposes of min_cdck calculation. This bumps the min
CDCLK sufficiently to overcome some kind of 2 PPC granularity
issue. Without this CDCLK may end up being too low and we get
underruns with certain horizontal downscale factors.
The current Bspec formula calls for doubling only the
fractional part below 0.5, and rounding it down to a
unit fraction. But that formula does not result in a
sufficient CDCLK bump in a lot of cases. Empirical evidence
supports doubling the entire fractional part, so let's just
do that while we wait for further analysis from the hardware
team.
Also note that the position of the scaler output window also
seems to matter. If the output is near the left edge of the
screen then lower CDCLK is sufficient, but moving the output
window further to the right causes underruns unless CDCLK is
also bumped. Some prefill happening during hblank already?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-5-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
We'll need to do additional adjustments to the pipe pixel rate
for the purposes of min CDCLK calculations. Add a new
crtc_state->pixel_rate_cdclk for that purpose. We'll leave the
original crtc_state->pixel_rate for data rate related calculations
since we presumably don't need those extra adjustments there.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-4-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
We'll need to check for the "does the platform do 2 pixels per clock?"
thing in a few places. Add a feature macro for it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-3-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
ecryptfs_exorcise_daemon() drops queued messages from a dying daemon
without holding ecryptfs_msg_ctx_lists_mux, but
ecryptfs_msg_ctx_alloc_to_free() requires that lock.
Take the list lock while moving the queued contexts back to the free
list to avoid racing with other global msg ctx list users.
Fixes: f66e883eb6 ("eCryptfs: integrate eCryptfs device handle into the module.")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Signed-off-by: Tyler Hicks <code@tyhicks.com>
ecryptfs_send_message_locked() moves a message context from the free
list to the allocated list before sending the request to the userspace
daemon.
If ecryptfs_send_miscdev() fails, the context is left on the
allocated list and cannot be reused. Move it back to the free list on
failure and clear the caller's pointer.
Fixes: f66e883eb6 ("eCryptfs: integrate eCryptfs device handle into the module.")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Signed-off-by: Tyler Hicks <code@tyhicks.com>
parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body
without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When
encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key()
sets decrypted_key_size = encrypted_key_size and performs two
out-of-bounds writes:
1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into
decrypted_key[64] via scatterlist, overflowing into the parent
ecryptfs_auth_tok struct.
2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes
into crypt_stat->key[64], corrupting root_iv, keysig_list, and
mutexes in ecryptfs_crypt_stat.
Only AES-192 (cipher code 0x08) enables this because it sets
crypt_stat->key_size = 24 independently of encrypted_key_size,
allowing crypto_skcipher_setkey() to succeed while encrypted_key_size
exceeds ECRYPTFS_MAX_KEY_BYTES.
The PKI decryption path (parse_tag_65_packet) already validates
decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path
omits this check.
Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather
than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also
protects the 512-byte encrypted_key[] buffer, so the former 512-byte
check is removed as redundant.
Fixes: 237fead619 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")
Cc: <stable@vger.kernel.org>
Signed-off-by: HanQuan <eilaimemedsnaimel@gmail.com>
[tyhicks: Adjust the code comment to refer to macros representing the
buffer sizes rather than mentioning the buffer size values since they
may change in the future]
Signed-off-by: Tyler Hicks <code@tyhicks.com>
vfio_msi_cap_len() lazily allocates the per-device MSI permission table:
vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT);
if (!vdev->msi_perm)
return -ENOMEM;
ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags);
if (ret) {
kfree(vdev->msi_perm);
return ret; /* vdev->msi_perm left dangling */
}
When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the
error path frees vdev->msi_perm but leaves the freed pointer stored in
it. vdev->msi_perm is not re-zeroed later because struct
vfio_pci_core_device is per-device and persists across open/close cycles,
and the vfio_config_init() error path returns without calling
vfio_config_free(). So the dangling pointer outlives the failed open.
That leads to two use-after-frees on the same device:
1. Reuse. The next vfio_config_init() sees the stale pointer at
"if (vdev->msi_perm) return len;" and reuses the freed object. MSI
config accesses in vfio_pci_config_rw_single() then dereference and
call the freed perm->readfn / perm->writefn function pointers.
2. Double free. A later vfio_config_free() runs free_perm_bits() and
kfree() on the already-freed object.
Fix it by NULLing vdev->msi_perm after the kfree(), matching the
NULL-after-free discipline already used in free_perm_bits() and
vfio_config_free().
BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961)
Read of size 8 at addr ffff88800fcc88d0 by task exploit/143
Call Trace:
...
kasan_report (mm/kasan/report.c:595)
vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961)
vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986)
vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599)
vfs_read (fs/read_write.c:572)
__x64_sys_pread64 (fs/read_write.c:764)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
...
Followed on device close by a double free of the same object:
Oops: general protection fault, probably for non-canonical address
0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:kfree (mm/slub.c:6711)
Call Trace:
vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861)
vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685)
vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777)
vfio_df_close (drivers/vfio/vfio_main.c:602)
vfio_device_fops_release (drivers/vfio/vfio_main.c:648)
__fput (fs/file_table.c:512)
__x64_sys_close (fs/open.c:1496)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
...
Kernel panic - not syncing: Fatal exception
Fixes: 30ea32ab19 ("vfio/pci: Fix potential memory leak in vfio_msi_cap_len")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://lore.kernel.org/r/20260705014010.1297885-1-xmei5@asu.edu
Signed-off-by: Alex Williamson <alex@shazbot.org>
Allocate VFIO ioctl requests dynamically instead of using VLAs. GCC 11.5.0
rejects initialized VLAs with:
error: variable-sized object may not be initialized
The replaced stack u8 arrays also do not guarantee native struct alignment
for the aliased pointers.
Fixes: 19faf6fd96 ("vfio: selftests: Add a helper library for VFIO selftests")
Fixes: 20face8c75 ("vfio: selftests: Add helper to set/override a vf_token")
Assisted-by: Codex:gpt-5.5-high
Reviewed-by: Vipin Sharma <vipinsh@google.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Alex Mastro <amastro@fb.com>
Link: https://lore.kernel.org/r/20260617-scratch-amastro-vfio-selftests-avoid-vlas-v4-2-b9f52f1e2c5a@fb.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Add {malloc,calloc}_assert() helpers alongside the existing *_assert()
helpers.
Use them for VFIO selftest allocations that immediately assert a
non-NULL result.
Assisted-by: Codex:gpt-5.5-high
Signed-off-by: Alex Mastro <amastro@fb.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20260617-scratch-amastro-vfio-selftests-avoid-vlas-v4-1-b9f52f1e2c5a@fb.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Add a new VFIO PCI driver for NVIDIA GPUs that enables DMA testing
via the Falcon (Fast Logic Controller) microcontrollers. This driver
extracts and adapts the DMA test functionality from NVIDIA's
gpu-admin-tools project and integrates it into the existing VFIO
selftest framework.
Falcons are general-purpose microcontrollers present on NVIDIA GPUs
that can perform DMA operations between system memory and device
memory. By leveraging Falcon DMA, this driver allows NVIDIA GPUs to
be tested alongside Intel IOAT and DSA devices using the same
selftest infrastructure.
The driver is named 'nv_falcon' to reflect that it specifically
controls the Falcon microcontrollers for DMA operations, rather
than exposing general GPU functionality.
Reference implementation:
https://github.com/NVIDIA/gpu-admin-tools
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Signed-off-by: Rubin Du <rubind@nvidia.com>
Acked-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20260609232855.3808971-5-rubind@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Allow drivers that cannot trigger MSI interrupts to leave the send_msi
callback NULL. Add an fcntl_set_msi_nonblock() wrapper that only sets
nonblocking mode when send_msi is available, and update ASSERT_NO_MSI()
to skip when the driver lacks MSI support. The send_msi test SKIPs and
mix_and_match skips the MSI portion per iteration.
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Signed-off-by: Rubin Du <rubind@nvidia.com>
Link: https://lore.kernel.org/r/20260609232855.3808971-4-rubind@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Add vfio_pci_cmd_set()/vfio_pci_cmd_clear() read-modify-write macros
for PCI_COMMAND in vfio_pci_device.h.
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Signed-off-by: Rubin Du <rubind@nvidia.com>
Link: https://lore.kernel.org/r/20260609232855.3808971-3-rubind@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
Add a chunking loop to vfio_pci_driver_memcpy() so that it breaks up
large memcpy requests into max_memcpy_size-sized chunks. This allows
callers to request any size without worrying about per-driver limits.
The memcpy_start()/memcpy_wait() semantics are unchanged.
Update the test to use 4x max_memcpy_size so it exercises the new
chunking path (4 iterations) while keeping execution fast for drivers
with small DMA transfer sizes.
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Signed-off-by: Rubin Du <rubind@nvidia.com>
Link: https://lore.kernel.org/r/20260609232855.3808971-2-rubind@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
hwicap_module_init() registers icap_class before reserving the
character-device region and registering the platform driver. If either
of those later steps fails, the init path must undo the successful class
registration before returning an error.
Route the chrdev registration failure through a class unwind label, and
let the platform-driver registration failure fall through the existing
chrdev unwind before unregistering the class. The normal module exit path
is unchanged.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: ef141a0bb0 ("[POWERPC] Xilinx: hwicap driver")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://patch.msgid.link/20260623085604.89284-1-mhun512@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are a couple of prints in handle_control_message() which should
have converted cpkt->id through virtio32_to_cpu() before passing to
a print.
This fixes the following (prototype) sparse warnings:
drivers/char/virtio_console.c:1538:17: warning: incorrect type in argument 4 (different base types)
drivers/char/virtio_console.c:1538:17: expected unsigned int
drivers/char/virtio_console.c:1538:17: got restricted __virtio32 [usertype] id
drivers/char/virtio_console.c:1553:25: warning: incorrect type in argument 3 (different base types)
drivers/char/virtio_console.c:1553:25: expected unsigned int
drivers/char/virtio_console.c:1553:25: got restricted __virtio32 [usertype] id
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Amit Shah <amit@kernel.org>
Link: https://patch.msgid.link/20260623092141.631355-1-ben.dooks@codethink.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a check to see if devm_kasprintf() is not NULL in
mchp_ipc_get_cluster_aggr_irq(), returning -ENOMEM if the function
failed.
Assisted-by: gkh_clanker_t1000
CC: Jassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
Link: https://patch.msgid.link/20260709131640.210914-1-griffin@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The header itself also includes <linux/types.h> and additional to that
doesn't make use of any symbol defined (transitively) by
<linux/mod_devicetable.h>. Also the .c files that include that header
don't need it (there is no direct include, only via <linux/greybus.h>):
$ git grep -l greybus\\.h | xargs grep -E "\<(acpi_device_id|amba_id|ap_device_id|apr_device_id|auxiliary_device_id|bcma_device_id|ccw_device_id|cdx_device_id|coreboot_device_id|css_device_id|dfl_device_id|dmi_(device|system)_id|eisa_device_id|fsl_mc_device_id|hda_device_id|hid_device_id|hv_vmbus_device_id|i2c_device_id|i3c_device_id|ieee1394_device_id|input_device_id|ipack_device_id|isapnp_device_id|ishtp_device_id|mcb_device_id|mdio_device_id|mei_cl_device_id|mhi_device_id|mips_cdmm_device_id|of_device_id|parisc_device_id|pci_device_id|pci_epf_device_id|pcmcia_device_id|platform_device_id|pnp_(card_)?device_id|rio_device_id|rpmsg_device_id|sdio_device_id|sdw_device_id|serio_device_id|slim_device_id|spi_device_id|spmi_device_id|ssam_device_id|ssb_device_id|tb_service_id|tee_client_device_id|typec_device_id|ulpi_device_id|usb_device_id|vchiq_device_id|virtio_device_id|wmi_device_id|x86_(cpu|device)_id|zorro_device_id|cpu_feature)\>"
drivers/greybus/es2.c:static const struct usb_device_id id_table[] = {
drivers/greybus/es2.c: const struct usb_device_id *id)
drivers/greybus/gb-beagleplay.c:static const struct of_device_id gb_beagleplay_of_match[] = {
drivers/staging/greybus/arche-platform.c:static const struct of_device_id arche_platform_of_match[] = {
drivers/greybus/es2.c includes <linux/usb.h>,
drivers/greybus/gb-beagleplay.c includes <linux/serdev.h> which provides
of_device_id via <linux/device.h>, similar
drivers/staging/greybus/arche-platform.c includes
<linux/platform_device.h> which also provides of_device_id.
So the #include can go away without further adaption.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/80964227feede2d8f1978f13f4219fcf9e63d8d0.1783354012.git.u.kleine-koenig@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
identify_descriptor() computes a string descriptor size from
desc->string.length.
Require the descriptor to contain the fixed string descriptor header
before reading the variable string length. The existing descriptor-size
check then reports the short descriptor.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260706091935.78020-1-pengpeng@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wine mailing lists were moved from winehq.org to list.winehq.org in December
2025. The old address no longer works.
Signed-off-by: Elizabeth Figura <zfigura@codeweavers.com>
Link: https://patch.msgid.link/20260701183214.13973-1-zfigura@codeweavers.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "removed" flag check in each tty op has a TOCTOU race with
__ipoctal_remove(): the device could be removed between the flag
check and the subsequent access to hardware resources (channel
registers via iowrite8, or xmit_buf in write_tty).
Close this race by introducing a read-write semaphore (remove_sem).
The tty ops acquire the read lock via guard(rwsem_read) for the
full duration of the operation, while __ipoctal_remove() acquires
the write lock via scoped_guard(rwsem_write) when setting the
removed flag. This ensures that once removed is true, no in-flight
tty op can still be accessing resources that are about to be freed
by the remove path.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/fbce75010a0f0a3a3709a5e06fd0ffd19ca0a0ed.1782870760.git.xiaopei01@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Three issues arise when the device is removed while a tty session is
still active:
1. UAF of struct ipoctal: the remove callback frees ipoctal via
kfree() while tty ops may still access it. Fix by introducing
kref-based lifetime management — kref is taken in install() when
a tty is opened and released in cleanup() when the tty is finally
destroyed; remove() uses kref_put() instead of kfree().
2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove()
frees xmit_buf via tty_port_free_xmit_buf() while a userspace
process may still hold the tty fd and call write(). Fix by
checking for NULL xmit_buf in ipoctal_write_tty().
3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev)
dereferences ipoctal->dev after the ipack_device has been freed
by ipack_device_del(). Fix by caching ipoctal->carrier_owner
during probe() and calling module_put() on the cached pointer
directly in cleanup(), avoiding any access to ipoctal->dev.
Also introduce a "removed" flag in struct ipoctal, set at the start
of __ipoctal_remove(), and checked in every tty op that accesses
hardware resources (port_activate, write_tty, set_termios, hangup,
shutdown). This prevents page faults when devm_ioremap() regions
are unmapped after remove() returns.
Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
Closes: https://lore.kernel.org/lkml/178144969601.60470.1257088106279546587@gmail.com/
Fixes: 05e5027efc ("Staging: ipack: move out of staging")
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/e3b0a90b07f079c5bcd5ca90d1dd3b79bb29adb5.1782870760.git.xiaopei01@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The position pointer is only advanced if the return value of the write
operation is positive at ksys_write(). Therefore no need to manually
reset it when doing error handling.
Assisted-by: coccinelle # to find it
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20260717094519.20656-1-fmancera@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PPSETTIME64 supplies the timeval fields as s64 values, but
pp_set_timeout() narrows tv_usec to int and calculates tv_sec * HZ in a
signed long. Large positive values can therefore be truncated or overflow
and install an unintended timeout.
Keep both fields as s64, reject a non-canonical microsecond value, and
use timespec64_to_jiffies() to cap excessively large timeouts at
MAX_JIFFY_OFFSET. This is a behavior change because both PPSETTIME
ioctls could previously accept values with tv_usec >= USEC_PER_SEC.
The validation follows the precedent set by sock_set_timeout().
Fixes: 3b9ab374a1 ("ppdev: convert to y2038 safe")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260716013923.19494-1-lilinmao@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cache_setup_properties() sets use_arch_info = true when DT/ACPI
provide no cache nodes and the arch can derive the topology from
CPU registers (e.g. arm64 reading CLIDR_EL1), but still returns the
original -ENOENT. cache_shared_cpu_map_setup() bails on that error
before the new flag can take effect, so the first CPU brought online
always trips a misleading warning:
cacheinfo: Unable to detect cache hierarchy for CPU 0
Subsequent CPUs skip cache_setup_properties() entirely because
use_arch_info is now true, which is why only CPU0 hits it. This is
reproducible on arm64 with the QEMU 'virt' machine, whose default DT
has no cache nodes.
Clear ret after setting use_arch_info so the caller proceeds and
populates the shared cpu map via the arch-supplied leaves.
Fixes: ef9f643a9f ("cacheinfo: Add use_arch[|_cache]_info field/function")
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
Link: https://patch.msgid.link/20260611-cacheinfo-v2-1-6069ef066cf3@debian.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
irq_domain_add_linear() is going away as being obsolete now. Switch to
the preferred irq_domain_create_linear(). That differs in the first
parameter: It takes more generic struct fwnode_handle instead of struct
device_node. Therefore, of_fwnode_handle() is added around the
parameter.
Note some of the users can likely use dev->fwnode directly instead of
indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not
guaranteed to be set for all, so this has to be investigated on case to
case basis (by people who can actually test with the HW).
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Andrea della Porta <andrea.porta@suse.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Andrea della Porta <andrea.porta@suse.com>
Link: https://patch.msgid.link/20260708095733.385396-1-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
OpenDICE can also used on x86 platforms for attestation, one of the
usecase is Android's protected VM.
The OpenDICE device driver only supports device tree, adding ACPI
support so it can also be used on x86 environments easily.
The patch is verified using crosvm, with the following ACPI table passed
using --acpi-table, with --file-backed-mapping for the corresponding
memory region.
DefinitionBlock (
"opendice.aml", "SSDT", 2, "GOOGLE", "OpenDICE", 0x00000001
)
{
Scope (\_SB)
{
Device (DICE)
{
Name (_HID, "PRP0001")
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"compatible",
Package () { "google,open-dice" }
}
}
})
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadOnly, 0x9D1C3000, 0x00001000)
})
}
}
}
Signed-off-by: Song Guo <songguo@google.com>
Link: https://patch.msgid.link/20260715122146.4069884-4-songguo@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The reserved_mem only works on device tree systems.
This commit replaced it by phys_addr_t and resource_size_t to make it
possible to use open dice on non-DT platforms.
Signed-off-by: Song Guo <songguo@google.com>
Link: https://patch.msgid.link/20260715122146.4069884-3-songguo@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dev->of_node is not null only when the device is configured via device
tree. When the matching device is configured by other means (like ACPI),
the current code will cause null pointer dereference.
Signed-off-by: Song Guo <songguo@google.com>
Link: https://patch.msgid.link/20260715122146.4069884-2-songguo@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a mutex and take it around SBTSI read/write paths so that only
one transaction runs at a time. The lock is held only for the
duration of the bus transfer and associated driver bookkeeping, not
across blocking work unrelated to SBTSI.
This is a concurrency hardening fix.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/20260710111642.850022-8-Akshay.Gupta@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Implement IOCTL interface for SB-TSI driver to enable userspace access
to TSI register read/write operations through the AMD Advanced Platform
Management Link (APML) protocol.
Add an ioctl command (SBTSI_IOCTL_REG_XFER_CMD) that accepts a register
address, data byte, and direction flag.
The mutex is taken on the ioctl path here; the hwmon path is placed
under the same lock in the next patch, which completes serialization between
the hwmon and ioctl paths.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
Link: https://patch.msgid.link/20260710111642.850022-7-Akshay.Gupta@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AMD SB-TSI temperature sensors can be accessed over both
I2C and I3C buses depending on the platform configuration.
Extend the SB-TSI driver to support both I2C and I3C bus interfaces
by selecting the appropriate transport based on the probed bus type.
The driver maintains backward compatibility with existing I2C
deployments while enabling support for systems using the I3C bus.
Register both I2C and I3C drivers using module_i3c_i2c_driver() and
update the Kconfig dependency from I2C to I3C_OR_I2C.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
Link: https://patch.msgid.link/20260710111642.850022-6-Akshay.Gupta@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Refactor shared probe procedures into sbtsi_probe_common() to ensure
that I2C and I3C probes focus solely on bus-specific allocation and
device configuration.
The utility function reads the configuration register via sbtsi_xfer(),
initializes ext_range_mode and read_order, assigns the driver data,
and registers the hwmon auxiliary device.
Routing register access through sbtsi_xfer() keeps the probe path
bus-agnostic, so no transfer logic has to be duplicated when SB-TSI over
I3C support is added in a later patch.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
Link: https://patch.msgid.link/20260710111642.850022-5-Akshay.Gupta@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move the I2C read/write byte operations from the sbtsi hwmon driver into
a common sbtsi_xfer() function in tsi-core.c.
This decouples the hwmon sensor driver from the underlying bus transport,
preparing for I3C support in a subsequent patch.
This patch does not introduce any functional changes. The updates are
limited to code organization/cleanup and should not affect the runtime
behavior of the driver
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/20260710111642.850022-4-Akshay.Gupta@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Extract the paired integer/decimal register reads and writes from the
hwmon read/write callbacks into sbtsi_temp_read() and sbtsi_temp_write()
helpers. This consolidates error handling and respects the ReadOrder bit
for atomic temperature latching.
This keeps register access independent while preserving existing hwmon
functionality.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/20260710111642.850022-3-Akshay.Gupta@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move SBTSI(Side-Band Temperature Sensor Interface) core functionality out
of the hwmon-only path and into drivers/misc/amd-sbi so it can be reused
by non-hwmon consumers.
I2C probe parsing is moved from drivers/hwmon/sbtsi_temp.c
into drivers/misc/amd-sbi/tsi.c under CONFIG_AMD_SBTSI. The core driver
stores struct sbtsi_data on the bus device and registers an auxiliary
device amd-sbtsi.temp-sensor.<addr> per target.
The current hwmon temp sensor will now require the CONFIG_AMD_SBTSI
configuration as a new dependency.
This split prepares the driver for additional interfaces while keeping
hwmon support in hwmon subsystem on top of common SBTSI core logic.
Add platform dependencies to clarify this driver is intended to run on
the BMC and not on the managed node.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/20260710111642.850022-2-Akshay.Gupta@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Switch from pci_enable_device() to pcim_enable_device() so the PCI device
is automatically disabled on probe error and driver removal. Drop the now
redundant manual pci_disable_device() and pci_clear_master() calls, since
pcim's release path clears bus mastering and disables the device.
Assisted-by: opencode:hy3-free
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260714025025.2055506-1-rosenp@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
