<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T11:56:28.837559+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bdu:2025-15699</id>
    <title>bdu:2025-15699</title>
    <updated>2026-10-03T11:56:29.492053+00:00</updated>
    <content>bdu:2025-15699</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-15699"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2025-39758</id>
    <title>BELL-CVE-2025-39758</title>
    <updated>2026-10-03T11:56:29.492133+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2025-39758"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895</id>
    <title>certfr-2025-avi-0895 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
    <updated>2026-10-03T11:56:29.492182+00:00</updated>
    <content>certfr-2025-avi-0895</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-357811</id>
    <title>EUVD-2026-357811</title>
    <updated>2026-10-03T11:56:29.492211+00:00</updated>
    <content>EUVD-2026-357811</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-357811"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2025-39758</id>
    <title>fkie_cve-2025-39758</title>
    <updated>2026-10-03T11:56:29.492232+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages</p>
<p>Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"),
we have been doing this:</p>
<p>static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset,
                             size_t size)
[...]
        /* Calculate the number of bytes we need to push, for this page
         * specifically */
        size_t bytes = min_t(size_t, PAGE_SIZE - offset, size);
        /* If we can't splice it, then copy it in, as normal */
        if (!sendpage_ok(page[i]))
                msg.msg_flags &amp;= ~MSG_SPLICE_PAGES;
        /* Set the bvec pointing to the page, with len $bytes */
        bvec_set_page(&amp;bvec, page[i], bytes, offset);
        /* Set the iter to $size, aka the size of the whole sendpages (!!!) */
        iov_iter_bvec(&amp;msg.msg_iter, ITER_SOURCE, &amp;bvec, 1, size);
try_page_again:
        lock_sock(sk);
        /* Sendmsg with $size size (!!!) */
        rv = tcp_sendmsg_locked(sk, &amp;msg, size);</p>
<p>This means we've been sending oversized iov_iters and tcp_sendmsg calls
for a while. This has a been a benign bug because sendpage_ok() always
returned true. With the recent slab allocator changes being slowly
introduced into next (that disallow sendpage on large kmalloc
allocations), we have recently hit out-of-bounds crashes, due to slight
differences in iov_iter behavior between the MSG_SPLICE_PAGES and
"regular" copy paths:</p>
<p>(MSG_S…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2025-39758"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-59wj-ff55-qrvj</id>
    <title>GHSA-59wj-ff55-qrvj</title>
    <updated>2026-10-03T11:56:29.492310+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages</p>
<p>Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"),
we have been doing this:</p>
<p>static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset,
                             size_t size)
[...]
        /* Calculate the number of bytes we need to push, for this page
         * specifically */
        size_t bytes = min_t(size_t, PAGE_SIZE - offset, size);
        /* If we can't splice it, then copy it in, as normal */
        if (!sendpage_ok(page[i]))
                msg.msg_flags &amp;= ~MSG_SPLICE_PAGES;
        /* Set the bvec pointing to the page, with len $bytes */
        bvec_set_page(&amp;bvec, page[i], bytes, offset);
        /* Set the iter to $size, aka the size of the whole sendpages (!!!) */
        iov_iter_bvec(&amp;msg.msg_iter, ITER_SOURCE, &amp;bvec, 1, size);
try_page_again:
        lock_sock(sk);
        /* Sendmsg with $size size (!!!) */
        rv = tcp_sendmsg_locked(sk, &amp;msg, size);</p>
<p>This means we've been sending oversized iov_iters and tcp_sendmsg calls
for a while. This has a been a benign bug because sendpage_ok() always
returned true. With the recent slab allocator changes being slowly
introduced into next (that disallow sendpage on large kmalloc
allocations), we have recently hit out-of-bounds crashes, due to slight
differences in iov_iter behavior between the MSG_SPLICE_PAGES and
"regular" copy paths:</p>
<p>(MSG_S…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-59wj-ff55-qrvj"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2025-39758</id>
    <title>msrc_CVE-2025-39758 — RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages</title>
    <updated>2026-10-03T11:56:29.492401+00:00</updated>
    <content>msrc_CVE-2025-39758</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2025-39758"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-1</id>
    <title>openSUSE-SU-2025:20081-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-03T11:56:29.492433+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2025:03600-1</id>
    <title>SUSE-SU-2025:03600-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-03T11:56:29.492887+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2025:03600-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39758</id>
    <title>UBUNTU-CVE-2025-39758</title>
    <updated>2026-10-03T11:56:29.493189+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 124 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages Ever since commit c2ff29e99a76 ("siw: Inline do_tcp_sendpages()"), we have been doing this: static int siw_tcp_sendpages(struct socket *s, struct page **page, int offset,                              size_t size) [...]         /* Calculate the number of bytes we need to push, for this page          * specifically */         size_t bytes = min_t(size_t, PAGE_SIZE - offset, size);         /* If we can't splice it, then copy it in, as normal */         if (!sendpage_ok(page[i]))                 msg.msg_flags &amp;= ~MSG_SPLICE_PAGES;         /* Set the bvec pointing to the page, with len $bytes */         bvec_set_page(&amp;bvec, page[i], bytes, offset);         /* Set the iter to $size, aka the size of the whole sendpages (!!!) */         iov_iter_bvec(&amp;msg.msg_iter, ITER_SOURCE, &amp;bvec, 1, size); try_page_again:         lock_sock(sk);         /* Sendmsg with $size size (!!!) */         rv = tcp_sendmsg_locked(sk, &amp;msg, size); This means we've been sending oversized iov_iters and tcp_sendmsg calls for a while. This has a been a benign bug because sendpage_ok() always returned true. With the recent slab allocator changes being slowly introduced into next (that disallow sendpage on large kmalloc allocations), we have recently hit out-of-bounds crashes, due to slight differences in iov_iter behavior between the MSG_SPLICE_PAGES and "regular" copy paths: (MSG_SPLICE…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39758"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2040</id>
    <title>WID-SEC-W-2025-2040 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
    <updated>2026-10-03T11:56:29.493500+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um Sicherheitsmechanismen zu umgehen, sowie einen Denial of Service Angriff oder andere nicht spezifizierte Angriffe durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2040"/>
  </entry>
</feed>
