Skip to main content

CVE-2022-49916: Vulnerability in Linux Linux

Medium
VulnerabilityCVE-2022-49916cvecve-2022-49916
Published: Thu May 01 2025 (05/01/2025, 14:10:56 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

In the Linux kernel, the following vulnerability has been resolved: rose: Fix NULL pointer dereference in rose_send_frame() The syzkaller reported an issue: KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387] CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: rcu_gp srcu_invoke_callbacks RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101 Call Trace: <IRQ> rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255 rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009 rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111 call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790 __run_timers kernel/time/timer.c:1768 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803 __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571 [...] </IRQ> It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is called in the rose_send_frame(). It's the first occurrence of the `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr. It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf ("rose: Fix Null pointer dereference in rose_send_frame()") ever. But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 ("rose: check NULL rose_loopback_neigh->loopback") again. We fix it by add NULL check in rose_transmit_clear_request(). When the 'dev' in 'neigh' is NULL, we don't reply the request and just clear it. syzkaller don't provide repro, and I provide a syz repro like: r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2) ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201}) r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0) bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40) connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)

AI-Powered Analysis

AILast updated: 06/28/2025, 01:10:10 UTC

Technical Analysis

CVE-2022-49916 is a vulnerability in the Linux kernel's ROSE (Radio Amateur Satellite Corporation) protocol implementation, specifically in the rose_send_frame() function. The issue is a NULL pointer dereference triggered when the kernel attempts to access 'neigh->dev->dev_addr' without verifying that 'neigh->dev' is non-NULL. This dereference occurs because the 'dev' field in the 'rose_loopback_neigh' structure can be initialized as NULL, and subsequent code paths do not properly check for this condition before usage. The problem was originally fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf but was reintroduced by a later commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8. The final fix involves adding a NULL check in rose_transmit_clear_request() to avoid replying to requests when 'dev' is NULL, instead clearing the request safely. The vulnerability was discovered via syzkaller, a kernel fuzzing tool, which reported a kernel address sanitizer (KASAN) null pointer dereference. The vulnerability affects multiple Linux kernel versions as indicated by various commit hashes. Exploitation requires triggering the rose protocol code paths, which are niche and not commonly used in most Linux deployments. No known exploits are reported in the wild, and no CVSS score has been assigned yet. The vulnerability could cause kernel crashes (denial of service) due to NULL pointer dereference, impacting system availability. The vulnerability does not appear to allow privilege escalation or code execution directly but could be leveraged in complex attack chains. The ROSE protocol is specialized and primarily used in amateur radio and satellite communications, limiting the attack surface. The vulnerability was responsibly disclosed and patched in the Linux kernel source.

Potential Impact

For European organizations, the impact of CVE-2022-49916 is generally limited due to the niche use of the ROSE protocol. Most enterprise and cloud Linux deployments do not enable or use ROSE networking, so the likelihood of exploitation is low. However, organizations involved in research, satellite communications, amateur radio, or specialized networking equipment that rely on the ROSE protocol could be affected. A successful exploitation would result in kernel crashes leading to denial of service, potentially disrupting critical systems or services. In environments where high availability is crucial, such as telecommunications or scientific research institutions, this could cause operational interruptions. Since the vulnerability does not require user interaction or authentication, any exposed system running vulnerable kernel versions with ROSE enabled could be impacted if an attacker can send crafted packets or requests. The lack of known exploits reduces immediate risk, but unpatched systems remain vulnerable to potential future attacks. European organizations using Linux kernels with the affected commits should prioritize patching to maintain system stability and security.

Mitigation Recommendations

1. Apply the official Linux kernel patches that fix this vulnerability as soon as possible. Monitor Linux kernel mailing lists and vendor advisories for updated kernel releases containing the fix. 2. Disable the ROSE protocol module if it is not required in your environment to reduce the attack surface. This can be done by blacklisting the 'rose' kernel module or recompiling the kernel without ROSE support. 3. For systems requiring ROSE, implement network-level filtering to restrict access to ROSE protocol traffic only to trusted sources, minimizing exposure to malicious packets. 4. Employ kernel hardening techniques such as Kernel Address Sanitizer (KASAN) and other runtime protections during development or testing phases to detect similar issues early. 5. Regularly audit and monitor kernel logs for unusual crashes or anomalies related to the rose_link.c code paths. 6. Coordinate with hardware and software vendors to ensure timely updates and support for patched kernels, especially in specialized communication equipment. 7. Incorporate this vulnerability into vulnerability management and patching workflows to ensure continuous compliance.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2025-05-01T14:05:17.251Z
Cisa Enriched
false
Cvss Version
null
State
PUBLISHED

Threat ID: 682d9821c4522896dcbdd785

Added to database: 5/21/2025, 9:08:49 AM

Last enriched: 6/28/2025, 1:10:10 AM

Last updated: 7/31/2025, 2:42:20 AM

Views: 12

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats