In the Linux kernel, the following vulnerability has been resolved:
cpufreq: amd-pstate: Remove unnecessary driver_lock in set_boost
set_boost is a per-policy function call, hence a driver wide lock is
unnecessary. Also this mutex_acquire can collide with the mutex_acquire
from the mode-switch path in status_store(), which can lead to a
deadlock. So, remove it.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled
When attempting to enable MQPRIO while HTB offload is already
configured, the driver currently returns `-EINVAL` and triggers a
`WARN_ON`, leading to an unnecessary call trace.
Update the code to handle this case more gracefully by returning
`-EOPNOTSUPP` instead, while also providing a helpful user message.
In the Linux kernel, the following vulnerability has been resolved:
serial: mctrl_gpio: split disable_ms into sync and no_sync APIs
The following splat has been observed on a SAMA5D27 platform using
atmel_serial:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:738
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0
preempt_count: 1, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c01588f0>] copy_process+0x1c4c/0x7bec
softirqs last enabled at (0): [<c0158944>] copy_process+0x1ca0/0x7bec
softirqs last disabled at (0): [<00000000>] 0x0
CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74
Hardware name: Atmel SAMA5
Workqueue: hci0 hci_power_on [bluetooth]
Call trace:
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x44/0x70
dump_stack_lvl from __might_resched+0x38c/0x598
__might_resched from disable_irq+0x1c/0x48
disable_irq from mctrl_gpio_disable_ms+0x74/0xc0
mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4
atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8
atmel_set_termios from uart_change_line_settings+0x15c/0x994
uart_change_line_settings from uart_set_termios+0x2b0/0x668
uart_set_termios from tty_set_termios+0x600/0x8ec
tty_set_termios from ttyport_set_flow_control+0x188/0x1e0
ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc]
wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth]
hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth]
hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth]
hci_power_on [bluetooth] from process_one_work+0x998/0x1a38
process_one_work from worker_thread+0x6e0/0xfb4
worker_thread from kthread+0x3d4/0x484
kthread from ret_from_fork+0x14/0x28
This warning is emitted when trying to toggle, at the highest level,
some flow control (with serdev_device_set_flow_control) in a device
driver. At the lowest level, the atmel_serial driver is using
serial_mctrl_gpio lib to enable/disable the corresponding IRQs
accordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to
disable_irq (called in mctrl_gpio_disable_ms) being possibly called in
some atomic context (some tty drivers perform modem lines configuration
in regions protected by port lock).
Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one
and a blocking one. Replace mctrl_gpio_disable_ms calls with the
relevant version depending on whether the call is protected by some port
lock.
In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: h616: Reparent GPU clock during frequency changes
The H616 manual does not state that the GPU PLL supports
dynamic frequency configuration, so we must take extra care when changing
the frequency. Currently any attempt to do device DVFS on the GPU lead
to panfrost various ooops, and GPU hangs.
The manual describes the algorithm for changing the PLL
frequency, which the CPU PLL notifier code already support, so we reuse
that to reparent the GPU clock to GPU1 clock during frequency
changes.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn
The user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can
run on multiple platforms having different DMA architectures.
On some platforms there can be one FDQ for all flows in the RX channel
while for others there is a separate FDQ for each flow in the RX channel.
So far we have been relying on the skip_fdq argument of
k3_udma_glue_reset_rx_chn().
Instead of relying on the user to provide this information, infer it
based on DMA architecture during k3_udma_glue_request_rx_chn() and save it
in an internal flag 'single_fdq'. Use that flag at
k3_udma_glue_reset_rx_chn() to deicide if the FDQ needs
to be cleared for every flow or just for flow 0.
Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.
> ip link set eth1 down
> ip link set eth0 down
> ethtool -L eth0 rx 8
> ip link set eth0 up
> modprobe -r ti_am65_cpsw_nuss
[ 103.045726] ------------[ cut here ]------------
[ 103.050505] k3_knav_desc_pool size 512000 != avail 64000
[ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]
[ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas
p drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r
fkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool]
[ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011
[ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)
[ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]
[ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]
[ 103.154709] sp : ffff8000826ebbc0
[ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000
[ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0
[ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88
[ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000
[ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde
[ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000
[ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20
[ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100
[ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000
[ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000
[ 103.229274] Call trace:
[ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)
[ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss]
[ 103.244942] devm_action_release+0x14/0x20
[ 103.249040] release_nodes+0x3c/0x68
[ 103.252610] devres_release_all+0x8c/0xdc
[ 103.256614] device_unbind_cleanup+0x18/0x60
[ 103.260876] device_release_driver_internal+0xf8/0x178
[ 103.266004] driver_detach+0x50/0x9c
[ 103.269571] bus_remove_driver+0x6c/0xbc
[ 103.273485] driver_unregister+0x30/0x60
[ 103.277401] platform_driver_unregister+0x14/0x20
[ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss]
[ 103.288620] __arm64_sys_delete_module+0x17c/0x25c
[ 103.293404] invoke_syscall+0x44/0x100
[ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0
[ 103.301845] do_el0_svc+0x1c/0x28
[ 103.305155] el0_svc+0x28/0x98
---truncated---
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_ffa: Set dma_mask for ffa devices
Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer
lead to following warning:
WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124
In the Linux kernel, the following vulnerability has been resolved:
media: cx231xx: set device_caps for 417
The video_device for the MPEG encoder did not set device_caps.
Add this, otherwise the video device can't be registered (you get a
WARN_ON instead).
Not seen before since currently 417 support is disabled, but I found
this while experimenting with it.