summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-09-19cpufreq: Add defensive check during driver registrationZihuan Zhang
Currently, cpufreq allows drivers to implement both ->target() and ->target_index() callbacks, but that can lead to ambiguous or incorrect behavior. For this reason, prevent cpufreq drivers implementing both ->target() and ->target_index() at the same time from registering. This check can help to catch driver implementation mistakes early and improve overall robustness, without affecting existing valid drivers. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Link: https://patch.msgid.link/20250908085738.31602-1-zhangzihuan@kylinos.cn [ rjw: Subject adjustment and changelog rewrite ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-19cpufreq: intel_pstate: Enable HWP without EPP if DEC is enabledRafael J. Wysocki
So far, HWP has never been enabled without EPP (Energy-Performance Preference) interface support, since the lack of the latter indicates an incomplete implementation of HWP, which was the case on early development vehicle platforms. However, HWP can be expected to work if DEC (Dynamic Efficiency Control) is enabled as indicated by setting bit 27 in MSR_IA32_POWER_CTL (DEC enable bit). Accordingly, allow HWP to be enabled if the EPP interface is not supported so long as DEC is enabled in the processor. Still, the EPP control sysfs interface is useless when EPP is not supported, so do not expose it in that case. Link: https://lore.kernel.org/linux-pm/20250904000608.260817-2-srinivas.pandruvada@linux.intel.com/ Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Co-developed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-19ACPI: processor: idle: Redefine two functions as voidRafael J. Wysocki
Notice that acpi_processor_power_init() and acpi_processor_power_exit() don't need to return any values because their callers don't check them anyway, so redefine those functions as void. While at it, rearrange the code in acpi_processor_power_init() to reduce the indentation level, get rid of a redundant local variable in that function, and rephrase a code comment in it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
2025-09-19ACPI: processor: Update cpuidle driver check in __acpi_processor_start()Rafael J. Wysocki
Commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") moved the ACPI idle driver registration to acpi_processor_driver_init() and acpi_processor_power_init() does not register an idle driver any more. Accordingly, the cpuidle driver check in __acpi_processor_start() needs to be updated to avoid calling acpi_processor_power_init() without a cpuidle driver, in which case the registration of the cpuidle device in that function would lead to a NULL pointer dereference in __cpuidle_register_device(). Fixes: 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/5044465.31r3eYUQgx@rafael.j.wysocki [ rjw: Changelog update ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-19vfio/pds: replace bitmap_free with vfreeZilin Guan
host_seq_bmp is allocated with vzalloc but is currently freed with bitmap_free, which uses kfree internally. This mismach prevents the resource from being released properly and may result in memory leaks or other issues. Fix this by freeing host_seq_bmp with vfree to match the vzalloc allocation. Fixes: f232836a9152 ("vfio/pds: Add support for dirty page tracking") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://lore.kernel.org/r/20250913153154.1028835-1-zilin@seu.edu.cn Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2025-09-19vfio: return -ENOTTY for unsupported device featureAlex Mastro
The two implementers of vfio_device_ops.device_feature, vfio_cdx_ioctl_feature and vfio_pci_core_ioctl_feature, return -ENOTTY in the fallthrough case when the feature is unsupported. For consistency, the base case, vfio_ioctl_device_feature, should do the same when device_feature == NULL, indicating an implementation has no feature extensions. Signed-off-by: Alex Mastro <amastro@fb.com> Link: https://lore.kernel.org/r/20250908-vfio-enotty-v1-1-4428e1539e2e@fb.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2025-09-19hisi_acc_vfio_pci: Fix reference leak in hisi_acc_vfio_debug_initMiaoqian Lin
The debugfs_lookup() function returns a dentry with an increased reference count that must be released by calling dput(). Fixes: b398f91779b8 ("hisi_acc_vfio_pci: register debugfs for hisilicon migration driver") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Longfang Liu <liulongfang@huawei.com> Link: https://lore.kernel.org/r/20250901081809.2286649-1-linmq006@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2025-09-19vfio/platform: Mark reset drivers for removalAlex Williamson
While vfio-platform itself is on a reprieve from being removed[1], these reset drivers don't support any current hardware, are not being tested, and suggest a level of support that doesn't really exist. Mark them for removal to surface any remaining user such that we can potentially drop them and simplify the code if none appear. Link: https://lore.kernel.org/all/20250806170314.3768750-3-alex.williamson@redhat.com [1] Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20250825175807.3264083-3-alex.williamson@redhat.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2025-09-19vfio/amba: Mark for removalAlex Williamson
vfio-amba has only been touched to keep up with the rest of the code base for the past 10 years. We have no basis to believe that it's currently tested or used. Mark it for deprecation. Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/20250825175807.3264083-2-alex.williamson@redhat.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2025-09-19drm/dp: Add POST_LT_ADJ_REQ helpersVille Syrjälä
Add small helpers (drm_dp_post_lt_adj_req_supported() and drm_dp_post_lt_adj_req_in_progress()) to help with implementing the POST_LT_ADJ_REQ sequence. Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250718120154.15492-3-ville.syrjala@linux.intel.com
2025-09-19ASoC: fsl: fsl_qmc_audio: Reduce amount ofMark Brown
Merge series from Christophe Leroy <christophe.leroy@csgroup.eu>: This is a RESEND of v3 sent one month ago, see: https://lore.kernel.org/all/cover.1754993232.git.christophe.leroy@csgroup.eu/ This series reduces significantly the amount of interrupts on fsl_qmc_audio device. Patches 1 and 2 are preparatory patches. Patch 3 is the main change Patch 4 is a cleanup which is enabled by previous patch
2025-09-19Merge tag 'block-6.17-20250918' of git://git.kernel.dk/linuxLinus Torvalds
Pull block fixes from Jens Axboe: "A set of fixes for an issue with md array assembly and drbd for devices supporting write zeros" * tag 'block-6.17-20250918' of git://git.kernel.dk/linux: drbd: init queue_limits->max_hw_wzeroes_unmap_sectors parameter md: init queue_limits->max_hw_wzeroes_unmap_sectors parameter
2025-09-19Merge tag 'gpio-fixes-for-v6.17-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix an ACPI I2C HID driver breakage due to not initializing a structure on the stack and passing garbage down to GPIO core - ignore touchpad wakeup on GPD G1619-05 - fix debouncing configuration when looking up GPIOs in ACPI * tag 'gpio-fixes-for-v6.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpiolib: acpi: initialize acpi_gpio_info struct gpiolib: acpi: Ignore touchpad wakeup on GPD G1619-05 gpiolib: acpi: Program debounce when finding GPIO
2025-09-19Input: atmel_mxt_ts - add support for generic touchscreen configurationsSvyatoslav Ryhel
This provides support for generic touchscreen configuration options like swapped-x-y, min-x, min-y, size-x, size-y, etc. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://lore.kernel.org/r/20250909054903.11519-3-clamor95@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-09-19PCI: sg2042: Add Sophgo SG2042 PCIe driverChen Wang
Add support for PCIe controller in Sophgo SG2042 SoC. The controller uses the Cadence PCIe core programmed by pcie-cadence* common driver. The PCIe controller in SG2042 works in host mode only, supporting data rate up to 16 GT/s and lanes up to x16 or x8. Signed-off-by: Chen Wang <unicorn_wang@outlook.com> [mani: reworded description and minor code cleanups] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/01b0a57cd9dba8bed7c1f2d52997046c2c6f042b.1757643388.git.unicorn_wang@outlook.com
2025-09-19PCI: cadence: Check for the existence of cdns_pcie::ops before using itChen Wang
cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops. Hence, add a check to prevent NULL pointer dereference. Signed-off-by: Chen Wang <unicorn_wang@outlook.com> [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/35182ee1d972dfcd093a964e11205efcebbdc044.1757643388.git.unicorn_wang@outlook.com
2025-09-19can: esd_usb: Avoid errors triggered from USB disconnectStefan Mätje
The USB stack calls during disconnect the esd_usb_disconnect() callback. esd_usb_disconnect() calls netdev_unregister() for each network which in turn calls the net_device_ops::ndo_stop callback esd_usb_close() if the net device is up. The esd_usb_close() callback tries to disable all CAN Ids and to reset the CAN controller of the device sending appropriate control messages. Sending these messages in .disconnect() is moot and always fails because either the device is gone or the USB communication is already torn down by the USB stack in the course of a rmmod operation. Move the code that sends these control messages to a new function esd_usb_stop() which is approximately the counterpart of esd_usb_start() to make code structure less convoluted. Then change esd_usb_close() not to send the control messages at all if the ndo_stop() callback is executed from the USB .disconnect() callback. Add a new flag in_usb_disconnect to the struct esd_usb device structure to mark this condition which is checked by esd_usb_close() whether to skip the send operations in esd_usb_start(). Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Link: https://patch.msgid.link/20250821143422.3567029-6-stefan.maetje@esd.eu [mkl: minor change patch description to imperative language] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: esd_usb: Rework display of error messagesStefan Mätje
- esd_usb_open(): Get rid of duplicate "couldn't start device: %d\n" message already printed from esd_usb_start(). - Fix duplicate printout of network device name when network device is registered. Add an unregister message for the network device as counterpart to the register message. - Add the printout of error codes together with the error messages in esd_usb_close() and some in esd_usb_probe(). The additional error codes should lead to a better understanding what is really going wrong. - Convert all occurrences of error status prints to use "ERR_PTR(err)" instead of printing the decimal value of "err". - Rename retval to err in esd_usb_read_bulk_callback() to make the naming of error status variables consistent with all other functions. Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Link: https://patch.msgid.link/20250821143422.3567029-5-stefan.maetje@esd.eu [mkl: minor change patch description to imperative language] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19Merge tag 'mmc-v6.17-rc2-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC host fixes from Ulf Hansson: - mvsdio: Fix dma_unmap_sg() nents value - sdhci: Fix clock management for UHS-II - sdhci-pci-gli: Fix initialization of UHS-II for GL9767 * tag 'mmc-v6.17-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci-pci-gli: GL9767: Fix initializing the UHS-II interface during a power-on mmc: sdhci-uhs2: Fix calling incorrect sdhci_set_clock() function mmc: sdhci: Move the code related to setting the clock from sdhci_set_ios_common() into sdhci_set_ios() mmc: mvsdio: Fix dma_unmap_sg() nents value
2025-09-19can: rcar_can: Convert to %peGeert Uytterhoeven
Replace numerical error codes by mnemotechnic error codes, to improve the user experience in case of errors. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/adb2dc49c78b45191de410f645a5e423d341f94e.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: Do not print alloc_candev() failuresGeert Uytterhoeven
If alloc_candev() failed due to out-of-memory, the core memory allocation code has already printed an error message. If alloc_candev() failed for a different reason, alloc_netdev_mqs() has already printed an error message. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/2d6ad4be211a35492570fd7219ca7a89b384bfad.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: Mailbox bitfield conversionGeert Uytterhoeven
Convert CAN Mailbox Register field accesses to use the FIELD_PREP() and FIELD_GET() bitfield access macro. This gets rid of explicit shifts, and keeps a clear separation between hardware register layouts and offical CAN definitions. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/c75c7d6ed5929c4becf7c9178cec04a0731e8ab1.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: BCR bitfield conversionGeert Uytterhoeven
Convert CAN Bit Configuration Register field accesses to use the FIELD_PREP() bitfield access macro. While at it, fix the misspelling of BRP. This gets rid of custom function-like field preparation macros. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/01cfaedba2be22515ba8700893ea7f113df959c0.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: TFCR bitfield conversionGeert Uytterhoeven
Convert CAN Transmit FIFO Control Register field accesses to use the FIELD_GET() bitfield access macro. This gets rid of an explicit shift. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/a8b1dc6f1249a01af9b691ca59e2e5cc2dba6d44.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: CTLR bitfield conversionGeert Uytterhoeven
Convert CAN Control Register field accesses to use the FIELD_PREP() bitfield access macro. Add a few more comments and definitions while at it. This gets rid of explicit (and sometimes confusing) shifts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/077640e31949dc3c9d128a08ade94c9e9cd25672.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: Convert to GENMASK()Geert Uytterhoeven
Use the GENMASK() macro instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/3f947f0f91a8857a2cbce74807e42258e9f209ca.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: Convert to BIT()Geert Uytterhoeven
Use the BIT() macro instead of open-coding the same operation. Add a few more comments while at it. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/78fb16beb74975f6f6140ec9abb48beb94fb0afa.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: Convert to Runtime PMGeert Uytterhoeven
The R-Car CAN module is part of a Clock Domain on all supported SoCs. Hence convert its driver from explicit clock management to Runtime PM. While at it, use %pe to format error codes. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/68bfa5480a79c17c6ceec4fb073f33872e7ff5d0.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: Add helper variable dev to rcar_can_probe()Geert Uytterhoeven
rcar_can_probe() has many users of "pdev->dev". Introduce a shorthand to simplify the code. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/baf34c8bef5625ae73c830dbb3c617eb8f7adddd.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_can: Consistently use ndev for net_device pointersGeert Uytterhoeven
Most net_device pointers are named "ndev", but some are called "dev". Increase uniformity by always using "ndev". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/aac66fb5b5e1d6787121cf2ec36b551b41d4b32e.1755857536.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: peak_usb: fix shift-out-of-bounds issueStéphane Grosjean
Explicitly uses a 64-bit constant when the number of bits used for its shifting is 32 (which is the case for PC CAN FD interfaces supported by this driver). Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com> Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Closes: https://lore.kernel.org/20250917-aboriginal-refined-honeybee-82b1aa-mkl@pengutronix.de Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core") [mkl: update subject, apply manually] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19Merge tag 'pmdomain-v6.17-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm Pull pmdomain fixes from Ulf Hansson: "pmdomain core: - Restore behaviour for disabling unused PM domains and introduce the GENPD_FLAG_NO_STAY_ON configuration bit pmdomain providers: - renesas: Don't keep unused PM domains powered-on - rockchip: Fix regulator dependency with GENPD_FLAG_NO_STAY_ON" * tag 'pmdomain-v6.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: pmdomain: renesas: rmobile-sysc: Don't keep unused PM domains powered-on pmdomain: renesas: rcar-gen4-sysc: Don't keep unused PM domains powered-on pmdomain: renesas: rcar-sysc: Don't keep unused PM domains powered-on pmdomain: rockchip: Fix regulator dependency with GENPD_FLAG_NO_STAY_ON pmdomain: core: Restore behaviour for disabling unused PM domains pmdomain: renesas: rcar-sysc: Make rcar_sysc_onecell_np __initdata
2025-09-19can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflowVincent Mailhol
Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the mcba_usb driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on these lines: usb_msg.dlc = cf->len; memcpy(usb_msg.data, cf->data, usb_msg.dlc); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow. Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflowVincent Mailhol
Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, sun4ican_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on this line: dlc = cf->len; Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs a couple line below when doing: for (i = 0; i < dlc; i++) writel(cf->data[i], priv->base + (dreg + i * 4)); Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow. Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module") Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: hi311x: populate ndo_change_mtu() to prevent buffer overflowVincent Mailhol
Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. The driver will consume frame->len as-is with no further checks. This can result in a buffer overflow later on in hi3110_hw_tx() on this line: memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len); Here, frame->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow. Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver") Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflowVincent Mailhol
Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the etas_es58x driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)); to inject a malicious CAN XL frames. For example: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, es58x_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN(FD) frame. This can result in a buffer overflow. For example, using the es581.4 variant, the frame will be dispatched to es581_4_tx_can_msg(), go through the last check at the beginning of this function: if (can_is_canfd_skb(skb)) return -EMSGSIZE; and reach this line: memcpy(tx_can_msg->data, cf->data, cf->len); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU or CANFD_MTU (depending on the device capabilities). By fixing the root cause, this prevents the buffer overflow. Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces") Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: rcar_canfd: Fix controller mode settingDuy Nguyen
Driver configures register to choose controller mode before setting all channels to reset mode leading to failure. The patch corrects operation of mode setting. Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com> Signed-off-by: Tranh Ha <tranh.ha.xb@renesas.com> Link: https://patch.msgid.link/TYWPR01MB87434739F83E27EDCD23DF44B416A@TYWPR01MB8743.jpnprd01.prod.outlook.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19can: hi311x: fix null pointer dereference when resuming from sleep before ↵Chen Yufeng
interface was enabled This issue is similar to the vulnerability in the `mcp251x` driver, which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume from sleep before interface was brought up"). In the `hi311x` driver, when the device resumes from sleep, the driver schedules `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is not allocated and initialized, leading to a null pointer dereference. To fix this, we move the allocation and initialization of the workqueue from the `hi3110_open` function to the `hi3110_can_probe` function. This ensures that the workqueue is properly initialized before it is used during device resume. And added logic to destroy the workqueue in the error handling paths of `hi3110_can_probe` and in the `hi3110_can_remove` function to prevent resource leaks. Signed-off-by: Chen Yufeng <chenyufeng@iie.ac.cn> Link: https://patch.msgid.link/20250911150820.250-1-chenyufeng@iie.ac.cn Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-19Merge tag 'v6.17-p3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes a NULL pointer dereference in ccp and a couple of bugs in the af_alg interface" * tag 'v6.17-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg crypto: af_alg - Set merge to zero early in af_alg_sendmsg crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked()
2025-09-19net: intel: fm10k: Fix parameter idx set but not usedBrahmajit Das
Variable idx is set in the loop, but is never used resulting in dead code. Building with GCC 16, which enables -Werror=unused-but-set-parameter= by default results in build error. This patch removes the idx parameter, since all the callers of the fm10k_unbind_hw_stats_q as 0 as idx anyways. Suggested-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Brahmajit Das <listout@listout.xyz> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-19ixgbevf: fix proper type for error code in ixgbevf_resume()Aleksandr Loktionov
The variable 'err' in ixgbevf_resume() is used to store the return value of different functions, which return an int. Currently, 'err' is declared as u32, which is semantically incorrect and misleading. In the Linux kernel, u32 is typically reserved for fixed-width data used in hardware interfaces or protocol structures. Using it for a generic error code may confuse reviewers or developers into thinking the value is hardware-related or size-constrained. Replace u32 with int to reflect the actual usage and improve code clarity and semantic correctness. No functional change. Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-19iavf: fix proper type for error code in iavf_resume()Aleksandr Loktionov
The variable 'err' in iavf_resume() is used to store the return value of different functions, which return an int. Currently, 'err' is declared as u32, which is semantically incorrect and misleading. In the Linux kernel, u32 is typically reserved for fixed-width data used in hardware interfaces or protocol structures. Using it for a generic error code may confuse reviewers or developers into thinking the value is hardware-related or size-constrained. Replace u32 with int to reflect the actual usage and improve code clarity and semantic correctness. No functional change. Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-19idpf: add HW timestamping statisticsMilena Olech
Add HW timestamping statistics support - through implementing get_ts_stats. Timestamp statistics include correctly timestamped packets, discarded, skipped and flushed during PTP release. Most of the stats are collected per vport, only requests skipped due to lack of free latch index are collected per Tx queue. Statistics can be obtained using kernel ethtool since version 6.10 with: ethtool -I -T <interface> The output will include: Statistics: tx_pkts: 15 tx_lost: 0 tx_err: 0 Signed-off-by: Milena Olech <milena.olech@intel.com> Co-developed-by: Anton Nadezhdin <anton.nadezhdin@intel.com> Signed-off-by: Anton Nadezhdin <anton.nadezhdin@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-19ice: Remove deprecated ice_lag_move_new_vf_nodes() callDave Ertman
Moving the code to handle the LAG part of a VF reset to helper functions deprecated the function ice_lag_move_new_vf_nodes(). The cleanup missed a call to this function in the error path of ice_vc_cfg_qs_msg(). In the case that would end in the error path, a NULL pointer would be encountered due to the empty list of netdevs for members of the aggregate. Remove the unnecessary call to ice_lag_move_new_vf_nodes(), and since this is the only call to this function, remove the function as well. Fixes: 351d8d8ab6af ("ice: breakout common LAG code into helpers") Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Tested-by: Priya Singh <priyax.singh@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-19ice: add E830 Earliest TxTime First Offload supportPaul Greenwalt
E830 supports Earliest TxTime First (ETF) hardware offload, which is configured via the ETF Qdisc on a per-queue basis (see tc-etf(8)). ETF introduces a new Tx flow mechanism that utilizes a timestamp ring (tstamp_ring) alongside the standard Tx ring. This timestamp ring is used to indicate when hardware will transmit a packet. Tx Time is supported on the first 2048 Tx queues of the device, and the NVM image limits the maximum number of Tx queues to 2048 for the device. The allocation and initialization of the timestamp ring occur when the feature is enabled on a specific Tx queue via tc-etf. The requested Tx Time queue index cannot be greater than the number of Tx queues (vsi->num_txq). To support ETF, the following flags and bitmap are introduced: - ICE_F_TXTIME: Device feature flag set for E830 NICs, indicating ETF support. - txtime_txqs: PF-level bitmap set when ETF is enabled and cleared when disabled for a specific Tx queue. It is used by ice_is_txtime_ena() to check if ETF is allocated and configured on any Tx queue, which is checked during Tx ring allocation. - ICE_TX_FLAGS_TXTIME: Per Tx ring flag set when ETF is allocated and configured for a specific Tx queue. It determines ETF status during packet transmission and is checked by ice_is_txtime_ena() to verify if ETF is enabled on any Tx queue. Due to a hardware issue that can result in a malicious driver detection event, additional timestamp descriptors are required when wrapping around the timestamp ring. Up to 64 additional timestamp descriptors are reserved, reducing the available Tx descriptors. To accommodate this, ICE_MAX_NUM_DESC_BY_MAC is introduced, defining: - E830: Maximum Tx descriptor count of 8096 (8K - 32 - 64 for timestamp fetch descriptors). - E810 and E82X: Maximum Tx descriptor count of 8160 (8K - 32). Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Co-developed-by: Alice Michael <alice.michael@intel.com> Signed-off-by: Alice Michael <alice.michael@intel.com> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-19ice: move ice_qp_[ena|dis] for reusePaul Greenwalt
Move ice_qp_[ena|dis] and related helper functions to ice_base.c to allow reuse of these function currently only used by ice_xsk.c. Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-09-19HID: amd_sfh: Add sync across amd sfh work functionsBasavaraj Natikar
The process of the report is delegated across different work functions. Hence, add a sync mechanism to protect SFH work data across functions. Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Reported-by: Matthew Schwartz <matthew.schwartz@linux.dev> Closes: https://lore.kernel.org/all/a21abca5-4268-449d-95f1-bdd7a25894a5@linux.dev/ Tested-by: Prakruthi SP <Prakruthi.SP@amd.com> Co-developed-by: Akshata MukundShetty <akshata.mukundshetty@amd.com> Signed-off-by: Akshata MukundShetty <akshata.mukundshetty@amd.com> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-09-19Merge tag 'drm-fixes-2025-09-19' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Weekly fixes for drm, it's a bit busier than I'd like on the xe side this week, but otherwise amdgpu and some smaller fixes for i915/bridge and a revert on docs. docs: - fix docs build regression i915: - Honor VESA eDP backlight luminance control capability bridge: - anx7625: Fix NULL pointer dereference with early IRQ - cdns-mhdp8546: Fix missing mutex unlock on error path xe: - Release kobject for the failure path - SRIOV PF: Drop rounddown_pow_of_two fair - Remove type casting on hwmon - Defer free of NVM auxiliary container to device release - Fix a NULL vs IS_ERR - Add cleanup action in xe_device_sysfs_init - Fix error handling if PXP fails to start - Set GuC RCS/CCS yield policy amdgpu: - GC 11.0.1/4 cleaner shader support - DC irq fix - OD fix amdkfd: - S0ix fix" * tag 'drm-fixes-2025-09-19' of https://gitlab.freedesktop.org/drm/kernel: drm/amdgpu: suspend KFD and KGD user queues for S0ix drm/amdkfd: add proper handling for S0ix drm/xe/guc: Set RCS/CCS yield policy drm/xe: Fix error handling if PXP fails to start drm/xe/sysfs: Add cleanup action in xe_device_sysfs_init drm/amd: Only restore cached manual clock settings in restore if OD enabled drm/xe: Fix a NULL vs IS_ERR() in xe_vm_add_compute_exec_queue() drm: bridge: cdns-mhdp8546: Fix missing mutex unlock on error path drm/i915/backlight: Honor VESA eDP backlight luminance control capability drm/amd/display: Allow RX6xxx & RX7700 to invoke amdgpu_irq_get/put drm/amdgpu/gfx11: Add Cleaner Shader Support for GFX11.0.1/11.0.4 GPUs drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ drm/xe: defer free of NVM auxiliary container to device release callback drm/xe/hwmon: Remove type casting drm/xe/pf: Drop rounddown_pow_of_two fair LMEM limitation drm/xe/tile: Release kobject for the failure path Revert "drm: Add directive to format code in comment"
2025-09-19HID: intel-thc-hid: intel-quicki2c: support ACPI config for advanced featuresXinpeng Sun
There is a new BIOS enhancement that adds the capability to configure the following two features of I2C subsystem introduced in commit 1ed0b48 ("Intel-thc: Introduce max input size control") and commit 3f2a921 ("Intel-thc: Introduce interrupt delay control"): - Max input size control - Interrupt delay control As BIOS is used for the configuration of these two features, change driver data usage to indicate hardware capability, and add corresponding ACPI configuration support in QuickI2C driver. Signed-off-by: Xinpeng Sun <xinpeng.sun@intel.com> Tested-by: Rui Zhang <rui1.zhang@intel.com> Reviewed-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-09-19Merge remote-tracking branch 'origin' into for-6.18/intel-thc-hidJiri Kosina
Needed as a basisi for followup support for quicki2c advanced BIOS features. Signed-off-by: Jiri Kosina <jkosina@suse.com>