CVE, singkatan dari Common Vulnerabilities and Exposures, adalah daftar kerentanan keamanan komputer yang telah diungkapkan kepada publik.
OWASP
OWASP Top 10 adalah inisiatif yang mengidentifikasi dan mendokumentasikan 10 kerentanan keamanan teratas dalam aplikasi web.
CISA KEV
CISA Known Exploited Vulnerabilities (KEV) adalah inisiatif yang mengidentifikasi dan mempublikasikan daftar kerentanan yang diketahui telah dieksploitasi.
CPE, singkatan dari Common Platform Enumeration, adalah skema standar untuk penamaan perangkat keras, perangkat lunak, dan sistem operasi. CPE menyediakan skema penamaan terstruktur untuk mengidentifikasi dan mengklasifikasikan sistem teknologi informasi, platform, dan paket secara unik berdasarkan atribut tertentu seperti vendor, nama produk, versi, pembaruan, edisi, dan bahasa.
CWE, atau Common Weakness Enumeration, adalah daftar dan kategorisasi komprehensif tentang kelemahan dan kerentanan perangkat lunak. Ini berfungsi sebagai bahasa umum untuk mendeskripsikan kelemahan keamanan perangkat lunak dalam arsitektur, desain, kode, atau implementasi yang dapat menyebabkan kerentanan.
CAPEC, singkatan dari Common Attack Pattern Enumeration and Classification, adalah sumber daya publik yang komprehensif yang mendokumentasikan pola serangan umum yang digunakan oleh penyerang dalam serangan siber. Basis pengetahuan ini bertujuan untuk memahami dan mengartikulasikan kerentanan umum dan metode yang digunakan penyerang untuk mengeksploitasinya.
Layanan & Harga
Bantuan & Info
Cari : CVE id, CWE id, CAPEC id, vendor atau kata kunci dalam CVE
In the Linux kernel, the following vulnerability has been resolved:
netfs: fix reference leak
Commit 20d72b00ca81 ("netfs: Fix the request's work item to not
require a ref") modified netfs_alloc_request() to initialize the
reference counter to 2 instead of 1. The rationale was that the
requet's "work" would release the second reference after completion
(via netfs_{read,write}_collection_worker()). That works most of the
time if all goes well.
However, it leaks this additional reference if the request is released
before the I/O operation has been submitted: the error code path only
decrements the reference counter once and the work item will never be
queued because there will never be a completion.
This has caused outages of our whole server cluster today because
tasks were blocked in netfs_wait_for_outstanding_io(), leading to
deadlocks in Ceph (another bug that I will address soon in another
patch). This was caused by a netfs_pgpriv2_begin_copy_to_cache() call
which failed in fscache_begin_write_operation(). The leaked
netfs_io_request was never completed, leaving `netfs_inode.io_count`
with a positive value forever.
All of this is super-fragile code. Finding out which code paths will
lead to an eventual completion and which do not is hard to see:
- Some functions like netfs_create_write_req() allocate a request, but
will never submit any I/O.
- netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read()
and then netfs_put_request(); however, netfs_unbuffered_read() can
also fail early before submitting the I/O request, therefore another
netfs_put_request() call must be added there.
A rule of thumb is that functions that return a `netfs_io_request` do
not submit I/O, and all of their callers must be checked.
For my taste, the whole netfs code needs an overhaul to make reference
counting easier to understand and less fragile & obscure. But to fix
this bug here and now and produce a patch that is adequate for a
stable backport, I tried a minimal approach that quickly frees the
request object upon early failure.
I decided against adding a second netfs_put_request() each time
because that would cause code duplication which obscures the code
further. Instead, I added the function netfs_put_failed_request()
which frees such a failed request synchronously under the assumption
that the reference count is exactly 2 (as initially set by
netfs_alloc_request() and never touched), verified by a
WARN_ON_ONCE(). It then deinitializes the request object (without
going through the "cleanup_work" indirection) and frees the allocation
(with RCU protection to protect against concurrent access by
netfs_requests_seq_start()).
All code paths that fail early have been changed to call
netfs_put_failed_request() instead of netfs_put_request().
Additionally, I have added a netfs_put_request() call to
netfs_unbuffered_read() as explained above because the
netfs_put_failed_request() approach does not work there.
Informasi CVE
EPSS
EPSS adalah model penilaian yang memprediksi kemungkinan suatu kerentanan dieksploitasi.
Skor EPSS
Model EPSS menghasilkan skor probabilitas antara 0 dan 1 (0 hingga 100%). Semakin tinggi skor, semakin besar probabilitas bahwa suatu kerentanan akan dieksploitasi.
Tanggal
EPSS V0
EPSS V1
EPSS V2 (> 2022-02-04)
EPSS V3 (> 2025-03-07)
EPSS V4 (> 2025-03-17)
2025-10-21
–
–
–
–
0.02%
2025-10-26
–
–
–
–
0.02%
2025-11-18
–
–
–
–
0.02%
2025-11-21
–
–
–
–
0.03%
2025-12-10
–
–
–
–
0.03%
2026-02-22
–
–
–
–
0.04%
2026-03-01
–
–
–
–
0.04%
2026-03-22
–
–
–
–
0.02%
2026-04-05
–
–
–
–
0.03%
2026-05-10
–
–
–
–
0.03%
Persentil EPSS
Persentil digunakan untuk meranking CVE berdasarkan skor EPSS mereka. Misalnya, CVE di persentil ke-95 berdasarkan skor EPSS-nya lebih mungkin dieksploitasi daripada 95% CVE lainnya. Dengan demikian, persentil digunakan untuk membandingkan skor EPSS suatu CVE dengan CVE lainnya.