CVE-2022-50728 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
s390/lcs: Fix return type of lcs_start_xmit()
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals:
drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~ drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~
->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of lcs_start_xmit() to match the prototype's to resolve the warning and potential CFI failure, should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 04/21/2026
The vulnerability CVE-2022-50728 represents a critical type mismatch issue within the Linux kernel's s390 architecture networking subsystem, specifically affecting the LCS (Logical Channel Subchannel) driver implementation. This flaw manifests as an incorrect return type declaration in the lcs_start_xmit() function, which directly impacts kernel control flow integrity mechanisms. The issue becomes particularly significant when compiling with clang's kernel control flow integrity (kCFI) support through CONFIG_CFI_CLANG, as this feature enforces strict validation of indirect function call targets against expected prototypes to prevent return-oriented programming (ROP) attacks. The mismatch between the expected netdev_tx_t return type and the actual int return type creates a fundamental incompatibility that can lead to runtime failures including kernel panics or thread termination, effectively compromising system stability and security.
The technical root cause of this vulnerability lies in the improper function signature declaration within the s390/lcs.c driver file, where the lcs_start_xmit() function fails to match the expected return type signature defined in the net_device_ops structure. According to the Linux kernel networking framework standards, the ndo_start_xmit function pointer within struct net_device_ops must conform to the netdev_tx_t return type definition, which is an enumeration type specifically designed for network device transmission operations. The compilation errors reported by clang demonstrate this exact mismatch, showing that the function is declared to return int while the expected prototype requires netdev_tx_t. This type inconsistency violates the kernel's expected interface contracts and creates a potential security vector that could be exploited by attackers seeking to bypass control flow integrity protections, particularly when the system is configured with CFI support.
The operational impact of CVE-2022-50728 extends beyond simple compilation warnings to encompass potential system instability and security vulnerabilities in environments utilizing s390 architecture systems with clang-based kernel compilation. When the kernel is built with CONFIG_CFI_CLANG enabled, the control flow integrity checks will fail at runtime if the mismatched function signature is encountered during indirect function calls, leading to immediate system crashes or process termination. This vulnerability specifically affects IBM System/390 and z/Architecture systems that rely on the LCS driver for network connectivity, potentially disrupting critical enterprise networking operations. The issue becomes particularly dangerous when combined with other security mitigations, as it could provide an attack vector for bypassing kernel security protections that are designed to prevent exploitation techniques such as ROP chains. The vulnerability also demonstrates the importance of maintaining strict type consistency in kernel interfaces, as even seemingly minor mismatches can have cascading effects on system security and stability.
Mitigation strategies for CVE-2022-50728 focus on correcting the function signature mismatch to align with the expected netdev_tx_t return type required by the Linux kernel networking subsystem. The primary fix involves modifying the lcs_start_xmit() function declaration to return netdev_tx_t instead of int, ensuring compatibility with the struct net_device_ops ndo_start_xmit field expectations. This change directly addresses the root cause by making the function signature consistent with the kernel's expected interface contract, thereby eliminating the kCFI validation failures that would otherwise occur. System administrators should ensure that kernel builds targeting s390 architectures with clang support properly compile with the corrected function signature, and that all affected systems are updated to versions containing this fix. Additionally, organizations should review their kernel compilation configurations to ensure that proper type checking is enabled, particularly when using clang with CONFIG_CFI_CLANG, as this vulnerability highlights the critical importance of maintaining strict interface compliance in kernel subsystems. The fix aligns with security best practices outlined in CWE-665 and ATT&CK techniques related to kernel exploitation and control flow integrity bypass, emphasizing the necessity of proper type handling in security-critical kernel components.