summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-06tls: don't abort the connection on signal-interrupted sendsMaximilian Immanuel Brandtner
When a signal interrupts a blocking send, tls_tx_records() treats the resulting -ERESTARTSYS as a transmission failure and marks the socket errored via tls_err_abort() with the raw error code. Later syscalls return the kernel-internal errno 512 (ERESTARTSYS) to userspace, as the signal it stems from is no longer pending during syscall exit and thus never translated. An interrupted send is not a connection error: the partially sent record stays queued and is resent later. Interrupt error codes are therefore excluded from the abort in the same way as -EAGAIN. Fixes: b341ca51d267 ("tls: Fix tls_sw_sendmsg error handling") Signed-off-by: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com> Link: https://patch.msgid.link/20260805063109.1772314-1-maxbr@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06net: avoid theoretical races with ref drainJakub Kicinski
Technically, it's illegal to take a ref on a netdev just because we have a pointer on which we already hold a ref, with no other protection. This is because our simple per-cpu refcount implementation cannot atomically read the count. Let's make sure we cancel outstanding work and never queue more work for a device we know is dead. This way taking a ref on a dev we know is on the netdev_work_list is always going to be safe. Jiangshan Yi reports that the issues is caught by ref tracker infra leading to a warning: WARNING: lib/ref_tracker.c:322 at ref_tracker_free WARNING: lib/ref_tracker.c:246 at ref_tracker_dir_exit Reported-by: Jiangshan Yi <yijiangshan@kylinos.cn> Link: https://lore.kernel.org/20260731035135.3917308-2-yijiangshan@kylinos.cn Fixes: 12c765be84d2 ("net: turn the rx_mode work into a generic netdev_work facility") Link: https://patch.msgid.link/20260806022821.2079945-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06net: Defer netdev KOBJ_ADD uevent until the device is publishedDragos Tatulea
netdev_register_kobject() calls device_add(), which emits KOBJ_ADD and wakes udev, but register_netdevice() only makes the device findable by name later, in list_netdevice(). A udev worker that reacts to the uevent can therefore run against a device that no lookup can find yet. This used to be harmless because the ethtool ioctl took the rtnl_lock when looking the device up, and register_netdevice() runs under rtnl, so the worker simply blocked until registration finished. The commit in the fixes tag moved the lookup out from under rtnl for ops-locked drivers. Now there is a short window in register_netdevice() between netdev_register_kobject() until list_netdevice() when the device is not findable by name. This was reproduced with the mlx5 driver on a kernel with KASAN enabled during devlink reload: systemd-udevd's net_driver builtin gets -ENODEV from ETHTOOL_GDRVINFO, which was preventing interface renaming. Suppress the uevent in netdev_register_kobject() and emit it from register_netdevice() next to rtmsg_ifinfo(). This is the last point in register_netdevice() where no error can happen, so only fully registered devices are announced: the registration error paths never reach it, and the device_del() that unwinds them stays silent as well, leaving userspace with neither an add nor a remove. Fixes: f994752b1127 ("net: ethtool: optionally skip rtnl_lock on IOCTL path") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Shahar Shitrit <shshitrit@nvidia.com> Link: https://patch.msgid.link/20260806080758.2039586-2-dtatulea@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06MAINTAINERS: dpll: zl3073x: replace Prathosh Satish with Min LiIvan Vecera
Replace Prathosh Satish by Min Li as the Microchip co-maintainer of the ZL3073X DPLL driver. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260805155425.38808-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06sctp: clear control chunk transport if it is being removedXin Long
sctp_make_heartbeat_ack() caches the destination transport in chunk->transport without taking a reference. When src_out_of_asoc_ok is enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead of being transmitted immediately. If the peer transport is removed while the chunk is still queued, sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing, but only clears cached transport pointers in out_chunk_list. The queued control chunk therefore retains a dangling transport pointer. Once an ASCONF_ACK clears the suppression and the queued control chunk is transmitted, SCTP dereferences the stale transport pointer, leading to a use-after-free. Fix this by also clearing chunk->transport for queued control chunks in control_chunk_list when removing the transport. Fixes: 8a07eb0a50ae ("sctp: Add ASCONF operation on the single-homed host") Reported-by: Daniele Linguaglossa <danielelinguaglossa@gmail.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/7e1168cb722132152a29d47e5eafaeac4a3bf6f3.1785943120.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06net/atm: fix slab-out-of-bounds read in vcc_setsockopt()Eric Dumazet
vcc_setsockopt() contained an ineffective optlen check: if (__SO_LEVEL_MATCH(optname, level) && optlen != __SO_SIZE(optname)) return -EINVAL; If __SO_LEVEL_MATCH(optname, level) evaluated to false (e.g. if the caller passed a mismatched level), the length check optlen != __SO_SIZE(optname) was short-circuited and bypassed. Execution then fell through to switch(optname), calling copy_from_sockptr() assuming optval contained sufficient space. Furthermore, even if level matched, a cgroup BPF setsockopt filter could shrink optlen after entry. Because copy_from_sockptr() on kernel pointers uses memcpy(), this leads to a KASAN slab-out-of-bounds read when optlen is smaller than the expected structure size. Fix this by using copy_safe_from_sockptr(), which unconditionally validates that optlen is at least the expected size before copying. Also change the local 'value' variable type from 'unsigned long' to 'int' so that SO_SETCLP matches its sizeof(int) ABI encoding on 64-bit systems. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+53ecc09fb81df10ef4de@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=53ecc09fb81df10ef4de Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260805131508.3227331-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06s390/ism: Fix UAF of sba and ieq during ism_dev_exit()Alexandra Winter
A ism interrupt handler can be active in parallel with ism_dev_exit(), accessing freed data structures. No new interrupts will be generated after unregister_ieq(). Drain ongoing interrupt handlers by free_irq(), before freeing ism data structures. Fixes: 684b89bc39ce ("s390/ism: add device driver for internal shared memory") Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Link: https://patch.msgid.link/20260805131043.954639-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06Merge branch 'net-fix-hard_header_len-races-in-packet-send-paths'Jakub Kicinski
Qihang Tang says: ==================== net: fix hard_header_len races in packet send paths The packet socket TX paths read dev->hard_header_len independently for skb allocation and header construction. Concurrent netdevice reconfiguration (e.g. bonding device type changes) can change this value in between, leading to mismatched headroom and copy length, and in the SOCK_RAW case to out-of-bounds writes. Patch 1 removes the CAP_SYS_RAWIO zero-padding branch in dev_validate_header(). That branch sizes a memset against the live dev->hard_header_len while operating on an skb whose headroom was allocated from an earlier hard_header_len read, so a concurrent increase can write past the reserved buffer. Removing it first keeps the later snapshot fixes bisect-safe: they do not replace an earlier skb_under_panic with a silent overwrite. Patches 2 and 3 snapshot hard_header_len once per send and use it consistently for allocation and construction, in the non-ring and TX_RING paths respectively. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create remains out of scope, as noted in the commit messages. ==================== Link: https://patch.msgid.link/20260805125729.19220-1-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06packet: use consistent hard_header_len in TX_RING send pathQihang Tang
tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here. Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260805125729.19220-4-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06packet: use consistent hard_header_len in non-ring send pathsQihang Tang
packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here. Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260805125729.19220-3-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06net: remove CAP_SYS_RAWIO zero-padding in dev_validate_headerQihang Tang
dev_validate_header() reads dev->hard_header_len directly when zero-padding short link layer headers for CAP_SYS_RAWIO holders: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Packet send paths call dev_validate_header() on skbs whose headroom was allocated from an earlier hard_header_len read. If the device is reconfigured so that dev->hard_header_len increases before validation, the memset writes past the reserved buffer, an out-of-bounds write. This out-of-bounds write is masked in some SOCK_RAW paths today because the same concurrent increase can first make skb_push() exceed the reserved headroom and trigger skb_under_panic(). Remove the zero-padding branch before making those hard_header_len reads consistent, so the snapshot fixes do not turn a loud panic into a silent overwrite. This path is only reached for variable length L2 protocols, where len < hard_header_len but len >= min_header_len. No remaining in-tree variable length L2 protocol implements header_ops->validate, and the CAP_SYS_RAWIO bypass that zero-pads and accepts short headers has no real value beyond allowing testing of intentionally malformed input. Drop the CAP_SYS_RAWIO branch. The remaining reads of dev->hard_header_len in dev_validate_header() are comparisons only and have no memory safety impact. Suggested-by: Willem de Bruijn <willemb@google.com> Fixes: 2793a23aacbd ("net: validate variable length ll headers") Cc: stable@vger.kernel.org Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260805125729.19220-2-q.h.hack.winter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06bnge: Fix resource leak in bnge_init_nic() error pathBhargava Marreddy
If bnge_init_chip() fails, bnge_init_nic() jumps to err_free_ring_grps and returns immediately, skipping cleanup for RX ring pair buffers. Remove the early return so execution falls through to err_free_rx_ring_pair_bufs to properly free resources on error. Fixes: 23df6aebf803 ("bng_en: Allocate stat contexts") Signed-off-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com> Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com> Reviewed-by: Rajashekar Hudumula <rajashekar.hudumula@broadcom.com> Link: https://patch.msgid.link/20260805094022.15487-1-bhargava.marreddy@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06fjes: cancel force_close_task in fjes_remove()Fan Wu
force_close_task runs on the system workqueue, which destroy_workqueue() does not drain, so it can run after free_netdev() and touch freed memory. Cancel it after destroying the workqueues, before free_netdev(). This issue was found by an in-house static analysis tool. Cc: stable+noautosel@kernel.org # untested fix to a driver init path race Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260805012337.416908-1-fanwu01@zju.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06fjes: unregister the netdev before destroying the workqueuesFan Wu
fjes_remove() destroys the driver workqueues before unregistering the netdev. The interrupt handler queues work on them, but the IRQ is only freed from fjes_close() under unregister_netdev(), so an interrupt in that window can queue work once the workqueues are gone. Unregister the netdev first so fjes_close() frees the IRQ and cancels the workers before the workqueues are destroyed. force_close_task, which the workers arm on the system workqueue, is handled in the next patch. This issue was found by an in-house static analysis tool. Cc: stable+noautosel@kernel.org # untested fix to a driver init path race Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260805011410.414431-1-fanwu01@zju.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06phy: freescale: fsl-samsung-hdmi: Balance runtime PM operationsFabio Estevam
fsl_samsung_hdmi_phy_probe() enables runtime PM, but the remove callback does not disable it. Unbinding and rebinding the device therefore results in the following warning on reprobe: Unbalanced pm_runtime_enable! Disable runtime PM after removing the clock provider. Also undo the runtime PM operations when phy_clk_register() fails. Otherwise, a failed probe leaves runtime PM enabled and the usage counter incremented. Signed-off-by: Fabio Estevam <festevam@nabladev.com> Link: https://patch.msgid.link/20260729192830.487150-1-festevam@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06ptp: ocp: Fix board ID over-readAhmad Byagowi
The EEPROM board ID is a fixed 13-byte field and is not guaranteed to contain a NUL terminator. Passing it directly to devlink_info_version_fixed_put() treats it as a C string and may read beyond the field. Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer before reporting the ID. Use a precision limit because the snprintf() output size alone does not bound the source string scan. Fixes: 0cfcdd1ebcfe ("ptp: ocp: add nvmem interface for accessing eeprom") Cc: stable@vger.kernel.org Signed-off-by: Ahmad Byagowi <ahmadexp@gmail.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260804210751.48248-1-ahmadexp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06ASoC: wm8904: don't use "/**" for non-kernel-doc commentsRandy Dunlap
Modify these errant comments to use "/*" since they are not kernel-doc comments. Warning: include/sound/wm8904.h:119 This comment starts with '/**', but isn't a kernel-doc comment. * DRC configurations are specified with a label and a set of register Warning: ../include/sound/wm8904.h:134 This comment starts with '/**', but isn't a kernel-doc comment. * ReTune Mobile configurations are specified with a label, sample Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260715000525.739874-15-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: qcom: audioreach: use C-style "/*" commentRandy Dunlap
Modify the "/**" to use "/*" instead since this is not a kernel-doc comment. This avoids all kernel-doc warnings in this header file: Warning: include/uapi/sound/snd_ar_tokens.h:61 Cannot find identifier on line: * %AR_TKN_U32_SUB_GRAPH_INSTANCE_ID: Sub Graph Instance Id Warning: ../include/uapi/sound/snd_ar_tokens.h:62 Cannot find identifier on line: * Warning: ../include/uapi/sound/snd_ar_tokens.h:63 Cannot find identifier on line: * %AR_TKN_U32_SUB_GRAPH_PERF_MODE: Performance mode of subgraph Warning: include/uapi/sound/snd_ar_tokens.h:64 This comment starts with '/**', but isn't a kernel-doc comment. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260715000525.739874-14-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: soc-acpi: fix all kernel-doc warningsRandy Dunlap
Add missing "struct" keyword to kernel-doc for structs. Describe @mach_params in struct snd_soc_acpi_mach. Don't document callback parameters with '@' as though they are kernel-doc. These changes avoid all kernel-doc warnings in this header file. Examples: Warning: ../include/sound/soc-acpi.h:77 cannot understand function prototype: 'struct snd_soc_acpi_mach_params' Warning: ../include/sound/soc-acpi.h:101 cannot understand function prototype: 'struct snd_soc_acpi_endpoint' Warning: ../include/sound/soc-acpi.h:115 cannot understand function prototype: 'struct snd_soc_acpi_adr_device' Warning: ../include/sound/soc-acpi.h:132 cannot understand function prototype: 'struct snd_soc_acpi_link_adr' Warning: ../include/sound/soc-acpi.h:209 cannot understand function prototype: 'struct snd_soc_acpi_mach' Warning: include/sound/soc-acpi.h:230 struct member 'mach_params' not described in 'snd_soc_acpi_mach' Warning: include/sound/soc-acpi.h:230 Excess struct member 'card' description in 'snd_soc_acpi_mach' Warning: include/sound/soc-acpi.h:230 Excess struct member 'mach' description in 'snd_soc_acpi_mach' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260715000525.739874-12-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: SDCA: correct enum names and add a missing struct fieldRandy Dunlap
Add a kernel-doc comment for @is_volatile in struct sdca_control. Correct 2 malformed enum names to match the enums. Fixes 3 warnings: Warning: include/sound/sdca_function.h:306 expecting prototype for enum sdca_set_index_range. Prototype was for enum sdca_fdl_set_index_range instead Warning: include/sound/sdca_function.h:829 struct member 'is_volatile' not described in 'sdca_control' Warning: include/sound/sdca_function.h:1152 expecting prototype for enum sdca_xu_reset_machanism. Prototype was for enum sdca_xu_reset_mechanism instead Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260715000525.739874-11-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: uniphier: don't use "/**" for non-kernel-doc commentRandy Dunlap
Use a C-style "/*" comment to avoid multiple kernel-doc warnings: Warning: ../sound/soc/uniphier/aio.h:159 Cannot find identifier on line: * 'SoftWare MAPping' setting of UniPhier AIO registers. Warning: ../sound/soc/uniphier/aio.h:160 Cannot find identifier on line: * Warning: ../sound/soc/uniphier/aio.h:161 This comment starts with '/**', but isn't a kernel-doc comment. * We have to setup 'virtual' register maps to access 'real' registers of AIO. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260715000525.739874-10-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: fsl: mpc5200_psc_i2s: avoid kernel-doc warningsRandy Dunlap
Add missing kernel-doc for function parameters. Use kernel-doc format for function return value descriptions. Use the "var" keyword to describe a data definition. These changes avoid all kernel-doc warnings in this file: Warning: ../sound/soc/fsl/mpc5200_psc_i2s.c:123 cannot understand function prototype: 'const struct snd_soc_dai_ops psc_i2s_dai_ops =' Warning: sound/soc/fsl/mpc5200_psc_i2s.c:87 function parameter 'cpu_dai' not described in 'psc_i2s_set_sysclk' Warning: sound/soc/fsl/mpc5200_psc_i2s.c:87 No description found for return value of 'psc_i2s_set_sysclk' Warning: sound/soc/fsl/mpc5200_psc_i2s.c:106 function parameter 'cpu_dai' not described in 'psc_i2s_set_fmt' Warning: sound/soc/fsl/mpc5200_psc_i2s.c:106 No description found for return value of 'psc_i2s_set_fmt' Warning: sound/soc/fsl/mpc5200_psc_i2s.c:123 cannot understand function prototype: 'const struct snd_soc_dai_ops psc_i2s_dai_ops =' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260715000525.739874-8-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: fsl_easrc: use struct keyword on structsRandy Dunlap
Use the documented format for kernel-doc of structs to prevent kernel-doc warnings: Warning: ../sound/soc/fsl/fsl_easrc.h:606 cannot understand function prototype: 'struct fsl_easrc_ctx_priv' Warning: ../sound/soc/fsl/fsl_easrc.h:641 cannot understand function prototype: 'struct fsl_easrc_priv' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260715000525.739874-6-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: fsl-dma: fix all kernel-doc warningsRandy Dunlap
Don't use "/**" for non-kernel-doc comments to avoid kernel-doc warnings: Warning: ../sound/soc/fsl/fsl_dma.h:95 This comment starts with '/**', but isn't a kernel-doc comment. * List Descriptor for extended chaining mode DMA operations. Warning: ../sound/soc/fsl/fsl_dma.h:110 This comment starts with '/**', but isn't a kernel-doc comment. * Link Descriptor for basic and extended chaining mode DMA operations. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260715000525.739874-5-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: fsl_asrc: avoid kernel-doc warningsRandy Dunlap
Use the struct keyword to describe structs in kernel-doc format. This prevents kernel-doc warnings: Warning: ../sound/soc/fsl/fsl_asrc.h:452 cannot understand function prototype: 'struct fsl_asrc_soc_data' Warning: ../sound/soc/fsl/fsl_asrc.h:463 cannot understand function prototype: 'struct fsl_asrc_pair_priv' Warning: ../sound/soc/fsl/fsl_asrc.h:475 cannot understand function prototype: 'struct fsl_asrc_priv' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260715000525.739874-4-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: codecs: NeoFidelity: repair the kernel-doc formatRandy Dunlap
Don't use "/**" for a non-kernel-doc comment. Use kernel-doc notation to document the parameters and return value of ntpfw_load(). Fixes these warnings: Warning: ../sound/soc/codecs/ntpfw.h:2 This comment starts with '/**', but isn't a kernel-doc comment. * ntpfw.h - Firmware helper functions for Neofidelity codecs Warning: sound/soc/codecs/ntpfw.h:20 function parameter 'i2c' not described in 'ntpfw_load' Warning: sound/soc/codecs/ntpfw.h:20 function parameter 'name' not described in 'ntpfw_load' Warning: sound/soc/codecs/ntpfw.h:20 function parameter 'magic' not described in 'ntpfw_load' Warning: sound/soc/codecs/ntpfw.h:20 No description found for return value of 'ntpfw_load' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260715000525.739874-2-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06perf trace-event: Fix buffer overflow in read_string()Tanushree Shah
read_string() writes into buf[BUFSIZ] one byte at a time without checking 'size' against the buffer bound before each write. A string longer than BUFSIZ in the input overflows the stack buffer. Add a bounds check before each write to prevent overflow. On overflow the function returns NULL, matching its other error paths. Fixes: 9215545e99d8 ("perf: Convert perf tracing data into a tracing_data event") Signed-off-by: Tanushree Shah <tshah@linux.ibm.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-08-06phy: phy-can-transceiver: default silent GPIO to high during probeHaibo Chen
The silent pin of the CAN transceiver is active high, asserting it puts the transceiver into silent (listen-only) mode where the transmitter is disabled. At probe time, and before the PHY is powered on, the transceiver should default to silent mode. This is the correct and lower-power state: the transceiver should not actively drive the CAN bus until the PHY is explicitly powered on. Requesting the silent GPIO as GPIOD_OUT_LOW leaves the transceiver in normal mode by default, which is both incorrect and wastes power. Request the silent GPIO as GPIOD_OUT_HIGH so the transceiver starts in silent mode, and let the power_on/power_off callbacks manage the mode afterwards. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260730-can-share-silent-v1-1-63fd603f943d@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06ALSA: portman2x4: Check card index validity at probeTakashi Iwai
Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260806153227.1460166-7-tiwai@suse.de
2026-08-06ALSA: mts64: Check card index validity at probeTakashi Iwai
Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260806153227.1460166-6-tiwai@suse.de
2026-08-06ALSA: virmidi: Check card index validity at probeTakashi Iwai
virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260806153227.1460166-5-tiwai@suse.de
2026-08-06ALSA: serial-u16550: Check card index validity at probeTakashi Iwai
serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260806153227.1460166-4-tiwai@suse.de
2026-08-06ALSA: mpu401: Check card index validity at probeTakashi Iwai
mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260806153227.1460166-3-tiwai@suse.de
2026-08-06ALSA: aloop: Check card index validity at probeTakashi Iwai
aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range. Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260806153227.1460166-2-tiwai@suse.de
2026-08-06ASoC: tac5xx2-sdw: remove firmware check restrictionNiranjan H Y
Firmware support should be available for all the devices in the family so that basic pre-processing blocks can be tuned with the firmware if it is available. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20260806053500.1955-2-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06ASoC: tac5xx2-sdw: add rev_id 0x30 supportNiranjan H Y
* HID interrupts: SDCA_12/SDCA_17 instead of was SDCA_11/SDCA_16 in in older revision. * UAJ port prepare: write 0xff (jack connected) or 0xdf (disconnected) This is required to solve the channel prepare timeout error during boot time with the 0x30 silicon. Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Link: https://patch.msgid.link/20260806053500.1955-1-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-06tls: rx: restore msg_iter before TLS 1.3 optimistic retryJérémy Jean
tls_decrypt_sg() advances msg->msg_iter when it maps user pages for the optimistic TLS 1.3 zero-copy path. If the decrypted record turns out not to be unpadded application data, tls_decrypt_sw() retries into a kernel skb, but leaves the iterator advanced. The subsequent copy from the skb then writes decrypted bytes again at a later point in the caller iovecs while recvmsg() reports only the post-retry length. A TLS peer can trigger this after the receiver enables TLS_RX_EXPECT_NO_PAD. Revert the iterator by the number of bytes consumed by the optimistic mapping before retrying without zero-copy. Add a selftest which sends a TLS 1.3 control record with TLS_RX_EXPECT_NO_PAD enabled and verifies that recvmsg() does not overwrite later iovecs beyond the returned length. Fixes: ce61327ce989 ("tls: rx: support optimistic decrypt to user buffer with TLS 1.3") Cc: stable@vger.kernel.org Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> Link: https://patch.msgid.link/20260804125528.2139928-1-Jeremy.Jean@oss.cyber.gouv.fr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06phy: rockchip: inno-hdmi: Remove deprecated way to configure TMDS rateJonas Karlman
The TMDS character rate of this PHY is configured using PHY bus width in downstream vendor kernel and out-of-tree patches, however no in-tree consumer of this PHY has ever called phy_set_bus_width() to change the TMDS character rate as currently only 8-bit RGB output is supported by the HDMI display driver. The series "Split Generic PHY consumer and provider" clarifies that phy_set_bus_width() is intended as a provider-only function. Remove the deprecated unused fallback way to configure TMDS character rate now that this HDMI PHY support using phy_configure() to configure the TMDS character rate. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> #rk3328 Tested-by: Diederik de Haas <diederik@cknow-tech.com> # Rock64 Link: https://patch.msgid.link/20260518180722.2480799-3-jonas@kwiboo.se Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06phy: rockchip: inno-hdmi: Add configure() and validate() opsJonas Karlman
The commit 10ed34d6eaaf ("phy: Add HDMI configuration options") introduced a way for HDMI PHYs to be configured through the generic phy_configure() function. This driver derives the TMDS character rate from the pixel clock and the PHY bus width setting. However, no in-tree consumer of this PHY has ever called phy_set_bus_width() to change the TMDS character rate as only 8-bit RGB output is supported by the HDMI display driver. Add configure() and validate() ops to allow consumers to configure the TMDS character rate using phy_configure(). Fallback to the deprecated way of using the PHY bus width to configure the TMDS character rate. A typical call chain during DRM modeset on a RK3328 device: dw_hdmi_rockchip_encoder_atomic_check(): - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000 dw_hdmi_rockchip_encoder_atomic_mode_set(): - inno_hdmi_phy_configure(): pixclock 148500000 - inno_hdmi_phy_validate(): pixclock 148500000 tmdsclock 594000000 vop_crtc_atomic_enable(): - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000 inno_hdmi_phy_rk3328_clk_set_rate(): pixclock 594000000 tmdsclock 594000000 - inno_hdmi_phy_rk3328_clk_recalc_rate(): pixclock 594000000 vco 594000000 dw_hdmi_rockchip_encoder_enable(): - inno_hdmi_phy_power_on(): Inno HDMI PHY Power On - inno_hdmi_phy_rk3328_clk_set_rate(): rate 594000000 tmdsclk 594000000 Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> #rk3328 Tested-by: Diederik de Haas <diederik@cknow-tech.com> # Rock64 Link: https://patch.msgid.link/20260518180722.2480799-2-jonas@kwiboo.se Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuningGerald Loacker
At high data rates like 4K60 (2500 Mbps), such as when using an LT6911GXD bridge chip on an RK3588 board, fixed default timing parameters can cause signal integrity issues and clock-data recovery failures. The driver currently lacks a mechanism to adjust the clock lane sampling phase to compensate for board-specific trace variations. Resolve this by parsing and applying the optional 'rockchip,clk-lane-phase' device tree property. This enables board-specific tuning of the clock lane sampling phase in ~40 ps steps (range 0-7) to optimize link stability. If the property is absent, the driver falls back to the hardware default. Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net> Reviewed-by: Michael Riesch <michael.riesch@collabora.com> Link: https://patch.msgid.link/20260725-feature-mipi-csi-dphy-4k60-v4-3-5b2c4626d31e@wolfvision.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase propertyGerald Loacker
Add support for the optional rockchip,clk-lane-phase device tree property to allow board-specific tuning of the clock lane sampling phase for improved signal integrity across supported data rates. Acked-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Michael Riesch <michael.riesch@collabora.com> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net> Link: https://patch.msgid.link/20260725-feature-mipi-csi-dphy-4k60-v4-2-5b2c4626d31e@wolfvision.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq tableGerald Loacker
The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this rate. This is essential for RK3588 reusing this array and fully supporting rates up to 2500 Mbps. Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy") Reviewed-by: Michael Riesch <michael.riesch@collabora.com> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net> Link: https://patch.msgid.link/20260725-feature-mipi-csi-dphy-4k60-v4-1-5b2c4626d31e@wolfvision.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06phy: sunplus: fix error handling in sp_uphy_init()Felix Gu
Fix the error paths of sp_uphy_init() to undo exactly what each stage did: return directly if clk_prepare_enable() fails, release only the clock if reset_control_deassert() fails, and jump to err_reset if update_disc_vol() fails so the clock and reset are not leaked. Fixes: 99d9ccd97385 ("phy: usb: Add USB2.0 phy driver for Sunplus SP7021") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patch.msgid.link/20260803-sunplus-usb3-v1-1-5a562524c869@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failureFelix Gu
for_each_child_of_node_scoped() releases the node reference on scope exit, so the explicit of_node_put(np) in the devm_phy_create() error path drops it twice. Drop the redundant of_node_put() and let the scoped cleanup handle it. Fixes: b64b32791fb5 ("phy: renesas: rcar-gen2: Simplify with scoped for each OF child loop") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260803-rcar-gen2-v1-1-9aa35c36d7d7@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06Merge branch 'tls-fix-plaintext-sk_msg-ring-over-fill'Jakub Kicinski
chanyoung says: ==================== tls: fix plaintext sk_msg ring over-fill An unprivileged user can oops the kernel by splicing into a kTLS socket whose open record already has a full plaintext sk_msg ring. Reproduced on net (53658c6f3682) with a stock config, no KASAN. Patch 2 oopses an unpatched kernel and passes with patch 1 applied. ==================== Link: https://patch.msgid.link/20260804052837.49015-1-ppoo1220@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06selftests: tls: add a test for splicing onto a full plaintext recordchanyoung
Splicing onto a plaintext sk_msg ring that is already full used to wrap the ring and make the kernel oops in the scatterwalk once the record was pushed. Only the copy path leaves the ring full without pushing it, so splice until the ring is one fragment short, add the last fragment with a one-byte MSG_MORE send, and splice once more before pushing the record. CONFIG_MAX_SKB_FRAGS is 17..45, so that last fragment follows between 16 and 44 splices; sweep that range to trigger the bug on any build. Signed-off-by: chanyoung <ppoo1220@gmail.com> Link: https://patch.msgid.link/20260804052837.49015-3-ppoo1220@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06tls: don't leave a full plaintext sk_msg ring unpushedchanyoung
When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills the plaintext sk_msg ring, it does not set full_record, so the record is left full and unpushed. A later splice() then adds to an already full ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps onto sg.start and the ring appears empty. Fragments added after that overwrite live entries, and sg.size no longer matches what is reachable between sg.start and sg.end, so pushing the record runs the scatterwalk off the end of the scatterlist. An unprivileged user can trigger this on a loopback TCP socket with the "tls" ULP attached: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0 Call Trace: skcipher_walk_next+0x1d1/0x2c0 gcm_encrypt_aesni_avx+0x1e9/0x220 bpf_exec_tx_verdict+0x3bb/0x860 tls_sw_sendmsg+0xa1a/0xca0 __sys_sendto+0x1da/0x1f0 Set full_record in the copy path when the ring becomes full, and push a record that is already full on entry to the sendmsg loop. Suggested-by: Sabrina Dubroca <sd@queasysnail.net> Fixes: fe1e81d4f73b ("tls/sw: Support MSG_SPLICE_PAGES") Cc: stable@vger.kernel.org Signed-off-by: chanyoung <ppoo1220@gmail.com> Link: https://patch.msgid.link/20260804052837.49015-2-ppoo1220@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-06drm/amd/display: Refactor stream validationIvan Lipski
[Why] amdgpu_dm_create_validate_stream_for_sink() drove its RGB -> YUV422 -> YUV420 chroma fallback by recursing and toggling the shared aconnector->force_yuv420_output / force_yuv422_output fields, resetting them after each recursive call. Those fields have no locking and the function runs concurrently on the same connector from two paths: the connector probe worker (->mode_valid) and a compositor's atomic check (dm_update_crtc_state). When both run at once, one thread can clear the override just before the other tests its exit condition, so the exit is missed and validation loops indefinitely, hanging the modeset path. [How] - Replace the recursion with an explicit loop over the chroma encodings wrapping the existing bpc walk. - Carry the encoding/bpc selection on the stack, passed by value into create_stream_for_sink() / fill_stream_properties_from_drm_display_mode(), instead of mutating shared connector state. - Derive the supported encodings and bit depths into bitmaps and drive validation from them, gating each candidate on the sink's advertised capability so unsupported encodings are never retried. - Move encoding selection entirely to the caller and pass the chosen dc_pixel_encoding into fill_stream_properties_from_drm_display_mode(). v2: sqaush in KUnit test fixes, merge with drm-misc changes (Alex) Assisted-by: Copilot:claude-opus-4.8 Reviewed-by: Jerry Zuo <jerry.zuo@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-08-07ata: pata_sl82c105: fix bridge revision use-after-freeHongyan Xu
pci_get_slot() returns a referenced PCI device. Commit 44c10138fd4b ("PCI: Change all drivers to use pci_device->revision") replaced a configuration-space read with direct access to the cached revision field, but left that access after pci_dev_put(). The bridge may therefore be freed before its revision is read. Read the revision before dropping the reference. Fixes: 44c10138fd4b ("PCI: Change all drivers to use pci_device->revision") Signed-off-by: Hongyan Xu <getshell@seu.edu.cn> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-08-06xdp: reject clones that overrun skb_shared_info tailroomZhiling Zou
xdpf_clone() clones broadcast copies into a single page and sets frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that page like a normal XDP frame and expects the usual skb_shared_info tailroom at the end of the buffer. The current check only rejects frames whose linear xdp_frame header, headroom, and packet data exceed PAGE_SIZE. A source frame backed by a larger allocation can still satisfy that check while extending into the clone's required shared-info area. When such a clone is converted back into an skb, build_skb_around() places skb_shared_info over live packet bytes and later writes can corrupt XDP return metadata. Reject clones unless their linear area fits inside SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already enforced by the XDP-to-skb conversion path. Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support") Cc: stable@vger.kernel.org Reported-by: Vega <vega@nebusec.ai> Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai> Link: https://patch.msgid.link/6b2afef5d1738763c6965e8e466eb16e43e4f956.1785757386.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org>