Siemens SIMATIC S7-1500 Missing Release of Memory after Effective Lifetime (CVE-2025-39756)

#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
##

include('compat.inc');

if (description)
{
  script_id(505152);
  script_version("1.3");
  script_set_attribute(attribute:"plugin_modification_date", value:"2026/07/17");

  script_cve_id("CVE-2025-39756");
  script_xref(name:"ICSA", value:"26-134-10");

  script_name(english:"Siemens SIMATIC S7-1500 Missing Release of Memory after Effective Lifetime (CVE-2025-39756)");

  script_set_attribute(attribute:"synopsis", value:
"The remote OT asset is affected by a vulnerability.");
  script_set_attribute(attribute:"description", value:
"In the Linux kernel, the following vulnerability has been resolved:
fs: Prevent file descriptor table allocations exceeding INT_MAX
When sysctl_nr_open is set to a very high value (for example,
1073741816  as set by systemd), processes attempting to use file
descriptors near  the limit can trigger massive memory allocation
attempts that exceed  INT_MAX, resulting in a WARNING in mm/slub.c:
WARNING: CPU: 0 PID: 44 at mm/slub.c:5027
__kvmalloc_node_noprof+0x21a/0x288    This happens because
kvmalloc_array() and kvmalloc() check if the  requested size exceeds
INT_MAX and emit a warning when the allocation is  not flagged with
__GFP_NOWARN.    Specifically, when nr_open is set to 1073741816
(0x3ffffff8) and a  process calls dup2(oldfd, 1073741880), the kernel
attempts to allocate:  - File descriptor array: 1073741880 * 8 bytes =
8,589,935,040 bytes  - Multiple bitmaps: ~400MB  - Total allocation
size: > 8GB (exceeding INT_MAX = 2,147,483,647)    Reproducer:  1. Set
/proc/sys/fs/nr_open to 1073741816:     # echo 1073741816 >
/proc/sys/fs/nr_open    2. Run a program that uses a high file
descriptor:     #include <unistd.h>     #include <sys/resource.h>
int main() {         struct rlimit rlim = {1073741824, 1073741824};
setrlimit(RLIMIT_NOFILE, &rlim);         dup2(2, 1073741880);  //
Triggers the warning         return 0;     }    3. Observe WARNING in
dmesg at mm/slub.c:5027    systemd commit a8b627a introduced automatic
bumping of fs.nr_open to the  maximum possible value. The rationale
was that systems with memory  control groups (memcg) no longer need
separate file descriptor limits  since memory is properly accounted.
However, this change overlooked  that:    1. The kernel's allocation
functions still enforce INT_MAX as a maximum     size regardless of
memcg accounting  2. Programs and tests that legitimately test file
descriptor limits can     inadvertently trigger massive allocations
3. The resulting allocations (>8GB) are impractical and will always
fail    systemd's algorithm starts with INT_MAX and keeps halving the
value  until the kernel accepts it. On most systems, this results in
nr_open  being set to 1073741816 (0x3ffffff8), which is just under 1GB
of file  descriptors.    While processes rarely use file descriptors
near this limit in normal  operation, certain selftests (like
tools/testing/selftests/core/unshare_test.c) and programs that test
file  descriptor limits can trigger this issue.    Fix this by adding
a check in alloc_fdtable() to ensure the requested  allocation size
does not exceed INT_MAX. This causes the operation to  fail with
-EMFILE instead of triggering a kernel warning and avoids the
impractical >8GB memory allocation request.

This plugin only works with Tenable.ot.
Please visit https://www.tenable.com/products/tenable-ot for more information.");
  script_set_attribute(attribute:"see_also", value:"https://cert-portal.siemens.com/productcert/html/ssa-082556.html");
  script_set_attribute(attribute:"see_also", value:"https://www.cisa.gov/news-events/ics-advisories/ICSA-26-134-10");
  script_set_attribute(attribute:"solution", value:
"Refer to the vendor advisory.");
  script_set_cvss_base_vector("CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C");
  script_set_cvss_temporal_vector("CVSS2#E:U/RL:OF/RC:C");
  script_set_cvss3_base_vector("CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H");
  script_set_cvss3_temporal_vector("CVSS:3.0/E:U/RL:O/RC:C");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2025-39756");

  script_set_attribute(attribute:"exploitability_ease", value:"No known exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"false");
  script_cwe_id(401);

  script_set_attribute(attribute:"vuln_publication_date", value:"2025/06/10");
  script_set_attribute(attribute:"patch_publication_date", value:"2025/06/10");
  script_set_attribute(attribute:"plugin_publication_date", value:"2026/02/16");

  script_set_attribute(attribute:"plugin_type", value:"remote");
  script_set_attribute(attribute:"cpe", value:"cpe:/o:siemens:simatic_s7-1500_cpu_firmware:3.1.5");
  script_set_attribute(attribute:"cpe", value:"cpe:/o:siemens:siplus_s7-1500_cpu_firmware:3.1.5");
  script_set_attribute(attribute:"generated_plugin", value:"former");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_family(english:"Tenable.ot");

  script_copyright(english:"This script is Copyright (C) 2026 and is owned by Tenable, Inc. or an Affiliate thereof.");

  script_dependencies("tenable_ot_api_integration.nasl");
  script_require_keys("Tenable.ot/Siemens");

  exit(0);
}


include('tenable_ot_cve_funcs.inc');

get_kb_item_or_exit('Tenable.ot/Siemens');

var asset = tenable_ot::assets::get(vendor:'Siemens');

var vuln_cpes = {
    "cpe:/o:siemens:simatic_s7-1500_cpu_firmware:3.1.5" :
        {"versionStartIncluding" : "3.1.5", "family" : "S71500", "orderNumbers" : ['6ES7518-4AX00-1AB0', '6ES7518-4FX00-1AC0', '6ES7518-4AX00-1AC0', '6ES7518-4FX00-1AB0']},
    "cpe:/o:siemens:siplus_s7-1500_cpu_firmware:3.1.5" :
        {"versionStartIncluding" : "3.1.5", "family" : "S71500", "orderNumbers" : ['6AG1518-4AX00-4AC0']}
};

tenable_ot::cve::compare_and_report(asset:asset, cpes:vuln_cpes, severity:SECURITY_WARNING);