CVSS base score: 7.8 (High) vendor CNA · v3.1
Score assigned by the vendor's own CVE Numbering Authority (CNA); CISA's Vulnrichment program adds a score only when the CNA omits one. Vulnrichment source record →
Vendor: Linux Product: Linux
In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd. Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd for 5.4 kernel ARM64: CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0 CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 PC is at : exports_net_open+0x50/0x68 [nfsd] Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248 Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu(). and same is happening on latest 6.14 kernel as well: [ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]--- It reproduced simply with below script: while [ 1 ] do /exportfs -r done & while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done & So exporting interfaces to user space shall be done at last and cleanup at first place. With change there is no Kernel OOPs.
No mentions found in monitored research blogs or news feeds.
| Date | Advisory | Issuer |
|---|---|---|
| 2026-10-22 | ICSA-26-295-11: Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP | CISA |
| 2026-07-28 | ICSA-26-209-04: Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP | CISA |
Each milestone comes from a different source, so gaps between them are gaps in what those sources publish, not evidence that nothing happened. EPSS history for this CVE holds 3 points from 2026-11-05, tracked daily from 2026-11-05; earlier points are weekly, which dates a spike to within a week. Peak probability 0.2% on 2026-11-07.
Check whether a specific version is affected →
What each source publishes about which product versions carry this vulnerability, kept as written rather than merged. Absence here means no source has published applicability data, not that nothing is affected.
Blind spot. No public detection — verify by version/patch. Nothing in the monitored scanner, IDS, SIEM or offensive-tool collections references this CVE, so exposure has to be established from asset inventory and patch level rather than from a signature.
Coverage across public collections only: Nuclei and OpenVAS NVT (scan);
Snort and Suricata ET Open (network); Sigma and YARA (host/SIEM);
Metasploit, Exploit-DB, public GitHub repositories and NVD exploit references (exploit). Absence
here means nothing public was found, not that detection is impossible.
GitHub PoC repositories are collected automatically by
PoC-in-GitHub (CC0) and filtered to repositories that are
still online, contain code, and are starred or at least two weeks old. They are
still not vetted: some are fakes and some are malware. Treat
them as evidence that code was published, not as code to run.
NVD exploit references are links NVD's analysts tag as exploits; they confirm
an exploit was referenced but carry no date. This product uses data from the
NVD but is not endorsed or certified by the NVD.
OpenVAS coverage derives from the Greenbone Community Feed, made available
under the Open Database License (ODbL) v1.0;
its individual Vulnerability Tests are licensed
GNU GPL v2.
No exploit-tool sightings recorded for this CVE.
Metasploit is dated by the first commit of the module file, Exploit-DB by its publication date, and GitHub repositories by their creation date. GitHub PoC repositories are filtered (still online, contain code, starred or at least two weeks old) but not vetted: some are fakes and some are malware, so they show that code was published, not that it works or is safe to run. Evidence tiers are explained on the About page.
Where the distribution has shipped a fix, and in which version. Green means the release has resolved it, amber that it is still open. Data from the Debian Security Tracker, used under Debian's MIT / GPLv2+ terms. Debian is upstream of several other distributions, so a fix here often precedes theirs.
| If the asset is | Remediate within | Table 1 row |
|---|---|---|
| Publicly exposed | 60 days | 8 of 16 |
| Not publicly exposed | Fix on system upgrade | 16 of 16 |
BOD 26-04 replaced the single KEV deadline of BOD 22-01 with four inputs: whether the asset is publicly exposed, KEV status, whether exploitation is automatable, and technical impact. Exposure belongs to each agency's asset, not to the CVE, so both outcomes are shown. Automatable and technical impact come from the CISA assessment above. Days are calendar days; for KEV entries the clock starts on the date it was added, and otherwise when the agency identifies the vulnerability on an asset. Agencies make the final exposure call asset by asset, and may set shorter timelines.
CVE.org record → NVD entry → FortiGuard Labs → Rapid7 AttackerKB →