CVE-2022-2048
published 2022-07-07CVE-2022-2048: In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly cleaning…
PriorityP339high7.5CVSS 3.1
AVNACLPRNUINSUCNINAH
EPSS
2.27%
81.1th percentile
In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly cleaning up the active connections and associated resources. This can lead to a Denial of Service scenario where there are no enough resources left to process good requests.
Affected
21 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | debian_linux | — | — |
| debian | debian_linux | — | — |
| debian | jetty9 | < jetty9 9.4.48-1 (bookworm) | jetty9 9.4.48-1 (bookworm) |
| eclipse | jetty | < 9.4.47 | 9.4.47 |
| eclipse | jetty | >= 10.0.0 < 10.0.9 | 10.0.9 |
| eclipse | jetty | >= 11.0.0 < 11.0.9 | 11.0.9 |
| jenkins | jenkins | < 2.263 | 2.263 |
| jenkins | jenkins | < 2.361.1 | 2.361.1 |
| jenkins | jenkins_core | — | — |
| jenkins | jenkins_lts | — | — |
| jenkins | jenkins_weekly | — | — |
| linux | linux_kernel | >= 5.14.0 < 5.15.86 | 5.15.86 |
| linux | linux_kernel | >= 5.16.0 < 5.19.17 | 5.19.17 |
| linux | linux_kernel | >= 5.16.0 < 6.0.16 | 6.0.16 |
| linux | linux_kernel | >= 5.20.0 < 6.0.3 | 6.0.3 |
| linux | linux_kernel | >= 5.8.0 < 5.15.75 | 5.15.75 |
| linux | linux_kernel | >= 6.1.0 < 6.1.2 | 6.1.2 |
| the_eclipse_foundation | eclipse_jetty | >= 10.0.0 < unspecified | unspecified |
| the_eclipse_foundation | eclipse_jetty | >= 11.0.0 < unspecified | unspecified |
| the_eclipse_foundation | eclipse_jetty | >= 9.4.0 < unspecified | unspecified |
| the_eclipse_foundation | eclipse_jetty | unspecified – 9.4.46 | — |
CVSS provenance
nvdv3.17.5HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
nvdv2.05.0MEDIUMAV:N/AC:L/Au:N/C:N/I:N/A:P
osv7.5HIGH
vendor_redhat7.8HIGH
vendor_debian7.5HIGH
vendor_oracle7.5HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
scsi: efct: Fix possible memleak in efct_device_init()
osv·2025-12-24
CVE-2022-50727 scsi: efct: Fix possible memleak in efct_device_init()
scsi: efct: Fix possible memleak in efct_device_init()
In the Linux kernel, the following vulnerability has been resolved:
scsi: efct: Fix possible memleak in efct_device_init()
In efct_device_init(), when efct_scsi_reg_fc_transport() fails,
efct_scsi_tgt_driver_exit() is not called to release memory for
efct_scsi_tgt_driver_init() and causes memleak:
unreferenced object 0xffff8881020ce000 (size 2048):
comm "modprobe", pid 465, jiffies 4294928222 (age 55.872s)
backtrace:
[] kmalloc_trace+0x27/0x110
[] target_register_template+0x4fd/0x7b0 [target_core_mod]
[] efct_scsi_tgt_driver_init+0x18/0x50 [efct]
[] 0xffffffffc0d90011
[] do_one_initcall+0xd0/0x4e0
[] do_init_module+0x1cc/0x6a0
...
OSV
powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe()
osv·2025-12-09
CVE-2022-50635 powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe()
powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe()
In the Linux kernel, the following vulnerability has been resolved:
powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe()
I found a null pointer reference in arch_prepare_kprobe():
# echo 'p cmdline_proc_show' > kprobe_events
# echo 'p cmdline_proc_show+16' >> kprobe_events
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc000000000050bfc
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in:
CPU: 0 PID: 122 Comm: sh Not tainted 6.0.0-rc3-00007-gdcf8e5633e2e #10
NIP: c000000000050bfc LR: c000000000050bec CTR: 0000000000005bdc
REGS
OSV
CVE-2022-2048: In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly
osv·2022-07-07·CVSS 7.5
CVE-2022-2048 [HIGH] CVE-2022-2048: In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly
In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly cleaning up the active connections and associated resources. This can lead to a Denial of Service scenario where there are no enough resources left to process good requests.
OSV
Jetty vulnerable to Invalid HTTP/2 requests that can lead to denial of service
osv·2022-07-07
CVE-2022-2048 [HIGH] Jetty vulnerable to Invalid HTTP/2 requests that can lead to denial of service
Jetty vulnerable to Invalid HTTP/2 requests that can lead to denial of service
### Description
Invalid HTTP/2 requests (for example, invalid URIs) are incorrectly handled by writing a blocking error response directly from the selector thread.
If the client manages to exhaust the HTTP/2 flow control window, or TCP congest the connection, the selector thread will be blocked trying to write the error response.
If this is repeated for all the selector threads, the server becomes unresponsive, causing the denial of service.
### Impact
A malicious client may render the server unresponsive.
### Patches
The fix is available in Jetty versions 9.4.47. 10.0.10, 11.0.10.
### Workarounds
No workaround available within Jetty itself.
One possible workaround is to filter the requests before sending th
GHSA
Jetty vulnerable to Invalid HTTP/2 requests that can lead to denial of service
ghsa·2022-07-07
CVE-2022-2048 [HIGH] CWE-400 Jetty vulnerable to Invalid HTTP/2 requests that can lead to denial of service
Jetty vulnerable to Invalid HTTP/2 requests that can lead to denial of service
### Description
Invalid HTTP/2 requests (for example, invalid URIs) are incorrectly handled by writing a blocking error response directly from the selector thread.
If the client manages to exhaust the HTTP/2 flow control window, or TCP congest the connection, the selector thread will be blocked trying to write the error response.
If this is repeated for all the selector threads, the server becomes unresponsive, causing the denial of service.
### Impact
A malicious client may render the server unresponsive.
### Patches
The fix is available in Jetty versions 9.4.47. 10.0.10, 11.0.10.
### Workarounds
No workaround available within Jetty itself.
One possible workaround is to filter the requests before sending th
OSV
Heap memory corruption with RSA private key operation
osv·2022-07-05
CVE-2022-2274 Heap memory corruption with RSA private key operation
Heap memory corruption with RSA private key operation
The OpenSSL 3.0.4 release introduced a serious bug in the RSA
implementation for X86_64 CPUs supporting the AVX512IFMA instructions.
This issue makes the RSA implementation with 2048 bit private keys
incorrect on such machines and memory corruption will happen during
the computation. As a consequence of the memory corruption an attacker
may be able to trigger a remote code execution on the machine performing
the computation.
SSL/TLS servers or other servers using 2048 bit RSA private keys running
on machines supporting AVX512IFMA instructions of the X86_64 architecture
are affected by this issue.
Note that on a vulnerable machine, proper testing of OpenSSL would fail and
should be noticed before deployment.
GHSA
openssl-src heap memory corruption with RSA private key operation
ghsa·2022-07-02
CVE-2022-2274 [CRITICAL] CWE-787 openssl-src heap memory corruption with RSA private key operation
openssl-src heap memory corruption with RSA private key operation
The OpenSSL 3.0.4 release introduced a serious bug in the RSA implementation for X86_64 CPUs supporting the AVX512IFMA instructions. This issue makes the RSA implementation with 2048 bit private keys incorrect on such machines and memory corruption will happen during the computation. As a consequence of the memory corruption an attacker may be able to trigger a remote code execution on the machine performing the computation. SSL/TLS servers or other servers using 2048 bit RSA private keys running on machines supporting AVX512IFMA instructions of the X86_64 architecture are affected by this issue.
Red Hat
kernel: rtc: class: Fix potential memleak in devm_rtc_allocate_device()
vendor_redhat·2025-10-04·CVSS 5.5
CVE-2022-50477 [MEDIUM] CWE-772 kernel: rtc: class: Fix potential memleak in devm_rtc_allocate_device()
kernel: rtc: class: Fix potential memleak in devm_rtc_allocate_device()
In the Linux kernel, the following vulnerability has been resolved:
rtc: class: Fix potential memleak in devm_rtc_allocate_device()
devm_rtc_allocate_device() will alloc a rtc_device first, and then run
dev_set_name(). If dev_set_name() failed, the rtc_device will memleak.
Move devm_add_action_or_reset() in front of dev_set_name() to prevent
memleak.
unreferenced object 0xffff888110a53000 (size 2048):
comm "python3", pid 470, jiffies 4296078308 (age 58.882s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff .........0......
08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00 .0..............
backtrace:
[] kmalloc_trace+0x21/0x110
[] devm_rtc_allocate_device+0xd4/0x400
[] devm_rtc_device_register+0
Red Hat
kernel: orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
vendor_redhat·2025-09-18·CVSS 5.5
CVE-2022-50376 [MEDIUM] kernel: orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
kernel: orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
In the Linux kernel, the following vulnerability has been resolved:
orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
When insert and remove the orangefs module, there are memory leaked
as below:
unreferenced object 0xffff88816b0cc000 (size 2048):
comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)
hex dump (first 32 bytes):
6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmalloc_trace+0x27/0xa0
[] orangefs_debugfs_init.cold+0xaf/0x17f
[] 0xffffffffa02780f9
[] do_one_initcall+0x87/0x2a0
[] do_init_module+0xdf/0x320
[] load_module+0x2f98/0x3330
[] __do_sys_finit_module+0x113/0x1b0
[] do_syscall_64+0x35/0x8
Red Hat
kernel: bpf: Fix memory leaks in __check_func_call
vendor_redhat·2025-05-01·CVSS 5.5
CVE-2022-49837 [MEDIUM] CWE-401 kernel: bpf: Fix memory leaks in __check_func_call
kernel: bpf: Fix memory leaks in __check_func_call
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix memory leaks in __check_func_call
kmemleak reports this issue:
unreferenced object 0xffff88817139d000 (size 2048):
comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmalloc_trace+0x27/0xa0
[] __check_func_call+0x316/0x1230
[] check_helper_call+0x172e/0x4700
[] do_check+0x21d8/0x45e0
[] do_check_common+0x767/0xaf0
[] bpf_check+0x43e3/0x5bc0
[] bpf_prog_load+0xf26/0x1940
[] __sys_bpf+0xd2c/0x3650
[] __x64_sys_bpf+0x75/0xc0
[] do_syscall_64+0x3b/0x90
[] entry_SYSCALL_64_after_hwfram
Red Hat
kernel: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()
vendor_redhat·2025-05-01·CVSS 5.5
CVE-2022-49800 [MEDIUM] kernel: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()
kernel: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()
test_gen_synth_cmd() only free buf in fail path, hence buf will leak
when there is no failure. Add kfree(buf) to prevent the memleak. The
same reason and solution in test_empty_synth_event().
unreferenced object 0xffff8881127de000 (size 2048):
comm "modprobe", pid 247, jiffies 4294972316 (age 78.756s)
hex dump (first 32 bytes):
20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test
20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_
backtrace:
[] kmalloc_trace+0x26/0x100
[] 0xffffffffa00083cd
[] 0xffffffffa00086ba
[] do_one_initcall+0xdb/0x4
Red Hat
kernel: drm/drv: Fix potential memory leak in drm_dev_init()
vendor_redhat·2025-05-01·CVSS 5.5
CVE-2022-49830 [MEDIUM] kernel: drm/drv: Fix potential memory leak in drm_dev_init()
kernel: drm/drv: Fix potential memory leak in drm_dev_init()
In the Linux kernel, the following vulnerability has been resolved:
drm/drv: Fix potential memory leak in drm_dev_init()
drm_dev_init() will add drm_dev_init_release() as a callback. When
drmm_add_action() failed, the release function won't be added. As the
result, the ref cnt added by device_get() in drm_dev_init() won't be put
by drm_dev_init_release(), which leads to the memleak. Use
drmm_add_action_or_reset() instead of drmm_add_action() to prevent
memleak.
unreferenced object 0xffff88810bc0c800 (size 2048):
comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s)
hex dump (first 32 bytes):
e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................
20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $] __kmalloc+0x4b/0x
Red Hat
kernel: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()
vendor_redhat·2025-05-01·CVSS 5.5
CVE-2022-49891 [MEDIUM] kernel: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()
kernel: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()
In the Linux kernel, the following vulnerability has been resolved:
tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()
test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak
when there is no failure. Move kfree(buf) from fail path to common path
to prevent the memleak. The same reason and solution in
test_gen_kretprobe_cmd().
unreferenced object 0xffff888143b14000 (size 2048):
comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s)
hex dump (first 32 bytes):
70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp
72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys
backtrace:
[] kmalloc_trace+0x27/0xa0
[] 0xffffffffa059006f
[] do_one_initcall+0x87/0x2a0
[] do
Red Hat
kernel: net: dsa: Fix possible memory leaks in dsa_loop_init()
vendor_redhat·2025-05-01·CVSS 5.5
CVE-2022-49926 [MEDIUM] CWE-401 kernel: net: dsa: Fix possible memory leaks in dsa_loop_init()
kernel: net: dsa: Fix possible memory leaks in dsa_loop_init()
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: Fix possible memory leaks in dsa_loop_init()
kmemleak reported memory leaks in dsa_loop_init():
kmemleak: 12 new suspected memory leaks
unreferenced object 0xffff8880138ce000 (size 2048):
comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s)
backtrace:
[] kmalloc_trace+0x26/0x60
[] phy_device_create+0x5d/0x970
[] get_phy_device+0xf3/0x2b0
[] __fixed_phy_register.part.0+0x92/0x4e0
[] fixed_phy_register+0x84/0xb0
[] dsa_loop_init+0xa9/0x116 [dsa_loop]
...
There are two reasons for memleak in dsa_loop_init().
First, fixed_phy_register() create and register phy_device:
fixed_phy_register()
get_phy_device()
phy_device_create() # freed by phy_device_
Red Hat
kernel: KVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2}
vendor_redhat·2024-06-20·CVSS 5.3
CVE-2022-48764 [MEDIUM] kernel: KVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2}
kernel: KVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2}
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2}
Free the "struct kvm_cpuid_entry2" array on successful post-KVM_RUN
KVM_SET_CPUID{,2} to fix a memory leak, the callers of kvm_set_cpuid()
free the array only on failure.
BUG: memory leak
unreferenced object 0xffff88810963a800 (size 2048):
comm "syz-executor025", pid 3610, jiffies 4294944928 (age 8.080s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 0d 00 00 00 ................
47 65 6e 75 6e 74 65 6c 69 6e 65 49 00 00 00 00 GenuntelineI....
backtrace:
[] kmalloc_node include/linux/slab.h:604 [inline]
[] kvmalloc_node+0x3e/0x100 mm/util.c:580
[] kvmalloc i
Oracle
Oracle Oracle Financial Services Applications Risk Matrix: Accessibility (Eclipse Jetty) — CVE-2022-2048
vendor_oracle·2023-07-15·CVSS 7.5
CVE-2022-2048 [HIGH] Oracle Oracle Financial Services Applications Risk Matrix: Accessibility (Eclipse Jetty) — CVE-2022-2048
Oracle Oracle Financial Services Applications Risk Matrix: Accessibility (Eclipse Jetty) vulnerability
CVE: CVE-2022-2048
CVSS: 7.5
Protocol: HTTP
Remote exploit: Yes
Affected versions: Network
Advisory: cpujul2023 (JUL 2023)
Oracle
Oracle Oracle Financial Services Applications Risk Matrix: Base (Eclipse Jetty) — CVE-2022-2048
vendor_oracle·2023-04-15·CVSS 7.5
CVE-2022-2048 [HIGH] Oracle Oracle Financial Services Applications Risk Matrix: Base (Eclipse Jetty) — CVE-2022-2048
Oracle Oracle Financial Services Applications Risk Matrix: Base (Eclipse Jetty) vulnerability
CVE: CVE-2022-2048
CVSS: 7.5
Protocol: HTTP
Remote exploit: Yes
Affected versions: Network
Advisory: cpuapr2023 (APR 2023)
Oracle
Oracle Oracle Communications Risk Matrix: Signaling (Eclipse Jetty) — CVE-2022-2048
vendor_oracle·2023-01-15·CVSS 7.5
CVE-2022-2048 [HIGH] Oracle Oracle Communications Risk Matrix: Signaling (Eclipse Jetty) — CVE-2022-2048
Oracle Oracle Communications Risk Matrix: Signaling (Eclipse Jetty) vulnerability
CVE: CVE-2022-2048
CVSS: 7.5
Protocol: HTTP
Remote exploit: Yes
Affected versions: Network
Advisory: cpujan2023 (JAN 2023)
Oracle
Oracle Oracle Communications Applications Risk Matrix: Message Bus (Eclipse Jetty) — CVE-2022-2048
vendor_oracle·2022-10-15·CVSS 7.5
CVE-2022-2048 [HIGH] Oracle Oracle Communications Applications Risk Matrix: Message Bus (Eclipse Jetty) — CVE-2022-2048
Oracle Oracle Communications Applications Risk Matrix: Message Bus (Eclipse Jetty) vulnerability
CVE: CVE-2022-2048
CVSS: 7.5
Protocol: HTTP
Remote exploit: Yes
Affected versions: Network
Advisory: cpuoct2022 (OCT 2022)
Jenkins
Jenkins Security Advisory 2022-09-09
vendor_jenkins·2022-09-09·CVSS 7.5
CVE-2022-2048 [HIGH] Jenkins Security Advisory 2022-09-09
Title: Jenkins Security Advisory 2022-09-09
Jenkins Security Advisory 2022-09-09
Jenkins Security Home
For Administrators
Overview
Terminology
Vulnerabilities and Scoring
Security Advisories
Security Issues
Advisory Schedule
Vulnerabilities in Plugins
How We Fix Security Issues
For Reporters
Reporting Vulnerabilities
Jenkins CNA
For Maintainers
Overview
Vulnerabilities in Plugins
Jenkins Security Team
About
Contributions
This advisory announces vulnerabilities in the following Jenkins deliverables:
Jenkins (core)
Descriptions
HTTP/2 denial of service vulnerability in bundled Jetty
SECURITY-2868
/
CVE-2022-2048
Severity (CVSS):
High
Description:
Jenkins bundles Winstone-Jet
Red Hat
http2-server: Invalid HTTP/2 requests cause DoS
vendor_redhat·2022-07-07·CVSS 7.5
CVE-2022-2048 [HIGH] CWE-410 http2-server: Invalid HTTP/2 requests cause DoS
http2-server: Invalid HTTP/2 requests cause DoS
In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly cleaning up the active connections and associated resources. This can lead to a Denial of Service scenario where there are no enough resources left to process good requests.
A flaw was found in the Eclipse Jetty http2-server package. This flaw allows an attacker to cause a denial of service in the server via HTTP/2 requests.
Package: http2-server (A-MQ Clients 2) - Not affected
Package: http2-server (Red Hat AMQ Broker 7) - Will not fix
Package: http2-server (Red Hat build of Debezium 1) - Not affected
Package: http2-server (Red Hat build of Quarkus) - Not affected
Package: http2-server
Debian
CVE-2022-2048: jetty9 - In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP...
vendor_debian·2022·CVSS 7.5
CVE-2022-2048 [HIGH] CVE-2022-2048: jetty9 - In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP...
In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly cleaning up the active connections and associated resources. This can lead to a Denial of Service scenario where there are no enough resources left to process good requests.
Scope: local
bookworm: resolved (fixed in 9.4.48-1)
bullseye: resolved (fixed in 9.4.39-3+deb11u1)
forky: resolved (fixed in 9.4.48-1)
sid: resolved (fixed in 9.4.48-1)
trixie: resolved (fixed in 9.4.48-1)
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2022-50727 kernel: scsi: efct: Fix possible memleak in efct_device_init()
bugzilla·2025-12-24
CVE-2022-50727 CVE-2022-50727 kernel: scsi: efct: Fix possible memleak in efct_device_init()
CVE-2022-50727 kernel: scsi: efct: Fix possible memleak in efct_device_init()
In the Linux kernel, the following vulnerability has been resolved:
scsi: efct: Fix possible memleak in efct_device_init()
In efct_device_init(), when efct_scsi_reg_fc_transport() fails,
efct_scsi_tgt_driver_exit() is not called to release memory for
efct_scsi_tgt_driver_init() and causes memleak:
unreferenced object 0xffff8881020ce000 (size 2048):
comm "modprobe", pid 465, jiffies 4294928222 (age 55.872s)
backtrace:
[] kmalloc_trace+0x27/0x110
[] target_register_template+0x4fd/0x7b0 [target_core_mod]
[] efct_scsi_tgt_driver_init+0x18/0x50 [efct]
[] 0xffffffffc0d90011
[] do_one_initcall+0xd0/0x4e0
[] do_init_module+0x1cc/0x6a0
...
Discussion:
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/202
Bugzilla
CVE-2022-50545 kernel: r6040: Fix kmemleak in probe and remove
bugzilla·2025-10-07·CVSS 5.5
CVE-2022-50545 [MEDIUM] CVE-2022-50545 kernel: r6040: Fix kmemleak in probe and remove
CVE-2022-50545 kernel: r6040: Fix kmemleak in probe and remove
In the Linux kernel, the following vulnerability has been resolved:
r6040: Fix kmemleak in probe and remove
There is a memory leaks reported by kmemleak:
unreferenced object 0xffff888116111000 (size 2048):
comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s)
hex dump (first 32 bytes):
00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................
08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmalloc_trace+0x22/0x60
[] phy_device_create+0x4e/0x90
[] get_phy_device+0xd2/0x220
[] mdiobus_scan+0xa4/0x2e0
[] __mdiobus_register+0x482/0x8b0
[] r6040_init_one+0x714/0xd2c [r6040]
...
The problem occurs in probe process as follows:
r6040_init_one:
mdiobus_register
mdiobus_scan mii_bus);
err_o
Bugzilla
CVE-2022-50376 kernel: orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
bugzilla·2025-09-18·CVSS 5.5
CVE-2022-50376 [MEDIUM] CVE-2022-50376 kernel: orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
CVE-2022-50376 kernel: orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
In the Linux kernel, the following vulnerability has been resolved:
orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
When insert and remove the orangefs module, there are memory leaked
as below:
unreferenced object 0xffff88816b0cc000 (size 2048):
comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)
hex dump (first 32 bytes):
6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmalloc_trace+0x27/0xa0
[] orangefs_debugfs_init.cold+0xaf/0x17f
[] 0xffffffffa02780f9
[] do_one_initcall+0x87/0x2a0
[] do_init_module+0xdf/0x320
[] load_module+0x2f98/0x3330
[] __do_sys_finit_module+0x113/0x1b0
[] do_s
Bugzilla
CVE-2022-49926 kernel: net: dsa: Fix possible memory leaks in dsa_loop_init()
bugzilla·2025-05-01·CVSS 5.5
CVE-2022-49926 [MEDIUM] CVE-2022-49926 kernel: net: dsa: Fix possible memory leaks in dsa_loop_init()
CVE-2022-49926 kernel: net: dsa: Fix possible memory leaks in dsa_loop_init()
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: Fix possible memory leaks in dsa_loop_init()
kmemleak reported memory leaks in dsa_loop_init():
kmemleak: 12 new suspected memory leaks
unreferenced object 0xffff8880138ce000 (size 2048):
comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s)
backtrace:
[] kmalloc_trace+0x26/0x60
[] phy_device_create+0x5d/0x970
[] get_phy_device+0xf3/0x2b0
[] __fixed_phy_register.part.0+0x92/0x4e0
[] fixed_phy_register+0x84/0xb0
[] dsa_loop_init+0xa9/0x116 [dsa_loop]
...
There are two reasons for memleak in dsa_loop_init().
First, fixed_phy_register() create and register phy_device:
fixed_phy_register()
get_phy_device()
phy_device_create()
Bugzilla
CVE-2022-49891 kernel: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()
bugzilla·2025-05-01·CVSS 5.5
CVE-2022-49891 [MEDIUM] CVE-2022-49891 kernel: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()
CVE-2022-49891 kernel: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()
In the Linux kernel, the following vulnerability has been resolved:
tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd()
test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak
when there is no failure. Move kfree(buf) from fail path to common path
to prevent the memleak. The same reason and solution in
test_gen_kretprobe_cmd().
unreferenced object 0xffff888143b14000 (size 2048):
comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s)
hex dump (first 32 bytes):
70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp
72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys
backtrace:
[] kmalloc_trace+0x27/0xa0
[] 0xffffffffa059006f
[] do_one_initcal
Bugzilla
CVE-2022-49800 kernel: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()
bugzilla·2025-05-01·CVSS 5.5
CVE-2022-49800 [MEDIUM] CVE-2022-49800 kernel: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()
CVE-2022-49800 kernel: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()
test_gen_synth_cmd() only free buf in fail path, hence buf will leak
when there is no failure. Add kfree(buf) to prevent the memleak. The
same reason and solution in test_empty_synth_event().
unreferenced object 0xffff8881127de000 (size 2048):
comm "modprobe", pid 247, jiffies 4294972316 (age 78.756s)
hex dump (first 32 bytes):
20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test
20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_
backtrace:
[] kmalloc_trace+0x26/0x100
[] 0xffffffffa00083cd
[] 0xffffffffa00086ba
[] do_one
Bugzilla
CVE-2022-49830 kernel: drm/drv: Fix potential memory leak in drm_dev_init()
bugzilla·2025-05-01·CVSS 5.5
CVE-2022-49830 [MEDIUM] CVE-2022-49830 kernel: drm/drv: Fix potential memory leak in drm_dev_init()
CVE-2022-49830 kernel: drm/drv: Fix potential memory leak in drm_dev_init()
In the Linux kernel, the following vulnerability has been resolved:
drm/drv: Fix potential memory leak in drm_dev_init()
drm_dev_init() will add drm_dev_init_release() as a callback. When
drmm_add_action() failed, the release function won't be added. As the
result, the ref cnt added by device_get() in drm_dev_init() won't be put
by drm_dev_init_release(), which leads to the memleak. Use
drmm_add_action_or_reset() instead of drmm_add_action() to prevent
memleak.
unreferenced object 0xffff88810bc0c800 (size 2048):
comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s)
hex dump (first 32 bytes):
e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................
20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $]
Bugzilla
CVE-2022-49837 kernel: bpf: Fix memory leaks in __check_func_call
bugzilla·2025-05-01·CVSS 5.5
CVE-2022-49837 [MEDIUM] CVE-2022-49837 kernel: bpf: Fix memory leaks in __check_func_call
CVE-2022-49837 kernel: bpf: Fix memory leaks in __check_func_call
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix memory leaks in __check_func_call
kmemleak reports this issue:
unreferenced object 0xffff88817139d000 (size 2048):
comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmalloc_trace+0x27/0xa0
[] __check_func_call+0x316/0x1230
[] check_helper_call+0x172e/0x4700
[] do_check+0x21d8/0x45e0
[] do_check_common+0x767/0xaf0
[] bpf_check+0x43e3/0x5bc0
[] bpf_prog_load+0xf26/0x1940
[] __sys_bpf+0xd2c/0x3650
[] __x64_sys_bpf+0x75/0xc0
[] do_syscall_64+0x3b/0x90
[] entry_SYSCA
http://www.openwall.com/lists/oss-security/2022/09/09/2https://github.com/eclipse/jetty.project/security/advisories/GHSA-wgmr-mf83-7x4jhttps://lists.debian.org/debian-lts-announce/2022/08/msg00011.htmlhttps://security.netapp.com/advisory/ntap-20220901-0006/https://www.debian.org/security/2022/dsa-5198http://www.openwall.com/lists/oss-security/2022/09/09/2https://github.com/eclipse/jetty.project/security/advisories/GHSA-wgmr-mf83-7x4jhttps://lists.debian.org/debian-lts-announce/2022/08/msg00011.htmlhttps://security.netapp.com/advisory/ntap-20220901-0006/https://www.debian.org/security/2022/dsa-5198
2022-07-07
Published