<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 28 Sep 2026 07:46:08 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-90125</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-90125</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2026-90125</guid>
    </item>
    <item>
      <title>fkie_cve-2026-90125</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-90125</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: fix request buffer leak in smb2_new_read_req()&lt;/p&gt;
&lt;p&gt;smb2_new_read_req() allocates the request buffer with
smb2_plain_req_init() but only publishes it to the caller with
*buf = req at the very end of the function. Two error returns sit in
between:&lt;/p&gt;
&lt;p&gt;rc = smb2_plain_req_init(SMB2_READ, io_parms-&amp;gt;tcon, server,
				 (void **) &amp;amp;req, total_len);
	if (rc)
		return rc;&lt;/p&gt;
&lt;p&gt;if (server == NULL)
		return -ECONNABORTED;
	[...]
		rdata-&amp;gt;mr = smbd_register_mr(server-&amp;gt;smbd_conn,
					     &amp;amp;rdata-&amp;gt;subreq.io_iter,
					     true, need_invalidate);
		if (!rdata-&amp;gt;mr)
			return -EAGAIN;&lt;/p&gt;
&lt;p&gt;On either of them the buffer is neither released nor handed back, so
it is leaked. The caller cannot clean up after it: smb2_async_readv()
does &amp;#39;goto out&amp;#39; on a non-zero return, which skips the
cifs_small_buf_release(buf) at async_readv_out, and buf has not been
assigned at that point in any case.&lt;/p&gt;
&lt;p&gt;The write path has never had this problem. smb2_async_writev()
registers the memory region inline and jumps to its release label
instead of returning:&lt;/p&gt;
&lt;p&gt;wdata-&amp;gt;mr = smbd_register_mr(...);
	if (!wdata-&amp;gt;mr) {
		rc = -EAGAIN;
		goto async_writev_out;
	}&lt;/p&gt;
&lt;p&gt;Commit b7972092199f (&amp;#34;cifs: smbd: Retry on memory registration
failure&amp;#34;) changed both sides from -ENOBUFS to -EAGAIN in a single
patch, which puts the two shapes next to each other.&lt;/p&gt;
&lt;p&gt;Only the -EAGAIN return is reachable in practice, because
smb2_plain_req_init() calls smb2_reconnect() first and t…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: fix request buffer leak in smb2_new_read_req()&lt;/p&gt;
&lt;p&gt;smb2_new_read_req() allocates the request buffer with
smb2_plain_req_init() but only publishes it to the caller with
*buf = req at the very end of the function. Two error returns sit in
between:&lt;/p&gt;
&lt;p&gt;rc = smb2_plain_req_init(SMB2_READ, io_parms-&amp;gt;tcon, server,
				 (void **) &amp;amp;req, total_len);
	if (rc)
		return rc;&lt;/p&gt;
&lt;p&gt;if (server == NULL)
		return -ECONNABORTED;
	[...]
		rdata-&amp;gt;mr = smbd_register_mr(server-&amp;gt;smbd_conn,
					     &amp;amp;rdata-&amp;gt;subreq.io_iter,
					     true, need_invalidate);
		if (!rdata-&amp;gt;mr)
			return -EAGAIN;&lt;/p&gt;
&lt;p&gt;On either of them the buffer is neither released nor handed back, so
it is leaked. The caller cannot clean up after it: smb2_async_readv()
does &amp;#39;goto out&amp;#39; on a non-zero return, which skips the
cifs_small_buf_release(buf) at async_readv_out, and buf has not been
assigned at that point in any case.&lt;/p&gt;
&lt;p&gt;The write path has never had this problem. smb2_async_writev()
registers the memory region inline and jumps to its release label
instead of returning:&lt;/p&gt;
&lt;p&gt;wdata-&amp;gt;mr = smbd_register_mr(...);
	if (!wdata-&amp;gt;mr) {
		rc = -EAGAIN;
		goto async_writev_out;
	}&lt;/p&gt;
&lt;p&gt;Commit b7972092199f (&amp;#34;cifs: smbd: Retry on memory registration
failure&amp;#34;) changed both sides from -ENOBUFS to -EAGAIN in a single
patch, which puts the two shapes next to each other.&lt;/p&gt;
&lt;p&gt;Only the -EAGAIN return is reachable in practice, because
smb2_plain_req_init() calls smb2_reconnect() first and t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-90125</guid>
    </item>
    <item>
      <title>GHSA-2f7p-h662-999p</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-2f7p-h662-999p</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: fix request buffer leak in smb2_new_read_req()&lt;/p&gt;
&lt;p&gt;smb2_new_read_req() allocates the request buffer with
smb2_plain_req_init() but only publishes it to the caller with
*buf = req at the very end of the function. Two error returns sit in
between:&lt;/p&gt;
&lt;p&gt;rc = smb2_plain_req_init(SMB2_READ, io_parms-&amp;gt;tcon, server,
				 (void **) &amp;amp;req, total_len);
	if (rc)
		return rc;&lt;/p&gt;
&lt;p&gt;if (server == NULL)
		return -ECONNABORTED;
	[...]
		rdata-&amp;gt;mr = smbd_register_mr(server-&amp;gt;smbd_conn,
					     &amp;amp;rdata-&amp;gt;subreq.io_iter,
					     true, need_invalidate);
		if (!rdata-&amp;gt;mr)
			return -EAGAIN;&lt;/p&gt;
&lt;p&gt;On either of them the buffer is neither released nor handed back, so
it is leaked. The caller cannot clean up after it: smb2_async_readv()
does &amp;#39;goto out&amp;#39; on a non-zero return, which skips the
cifs_small_buf_release(buf) at async_readv_out, and buf has not been
assigned at that point in any case.&lt;/p&gt;
&lt;p&gt;The write path has never had this problem. smb2_async_writev()
registers the memory region inline and jumps to its release label
instead of returning:&lt;/p&gt;
&lt;p&gt;wdata-&amp;gt;mr = smbd_register_mr(...);
	if (!wdata-&amp;gt;mr) {
		rc = -EAGAIN;
		goto async_writev_out;
	}&lt;/p&gt;
&lt;p&gt;Commit b7972092199f (&amp;#34;cifs: smbd: Retry on memory registration
failure&amp;#34;) changed both sides from -ENOBUFS to -EAGAIN in a single
patch, which puts the two shapes next to each other.&lt;/p&gt;
&lt;p&gt;Only the -EAGAIN return is reachable in practice, because
smb2_plain_req_init() calls smb2_reconnect() first and t…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: fix request buffer leak in smb2_new_read_req()&lt;/p&gt;
&lt;p&gt;smb2_new_read_req() allocates the request buffer with
smb2_plain_req_init() but only publishes it to the caller with
*buf = req at the very end of the function. Two error returns sit in
between:&lt;/p&gt;
&lt;p&gt;rc = smb2_plain_req_init(SMB2_READ, io_parms-&amp;gt;tcon, server,
				 (void **) &amp;amp;req, total_len);
	if (rc)
		return rc;&lt;/p&gt;
&lt;p&gt;if (server == NULL)
		return -ECONNABORTED;
	[...]
		rdata-&amp;gt;mr = smbd_register_mr(server-&amp;gt;smbd_conn,
					     &amp;amp;rdata-&amp;gt;subreq.io_iter,
					     true, need_invalidate);
		if (!rdata-&amp;gt;mr)
			return -EAGAIN;&lt;/p&gt;
&lt;p&gt;On either of them the buffer is neither released nor handed back, so
it is leaked. The caller cannot clean up after it: smb2_async_readv()
does &amp;#39;goto out&amp;#39; on a non-zero return, which skips the
cifs_small_buf_release(buf) at async_readv_out, and buf has not been
assigned at that point in any case.&lt;/p&gt;
&lt;p&gt;The write path has never had this problem. smb2_async_writev()
registers the memory region inline and jumps to its release label
instead of returning:&lt;/p&gt;
&lt;p&gt;wdata-&amp;gt;mr = smbd_register_mr(...);
	if (!wdata-&amp;gt;mr) {
		rc = -EAGAIN;
		goto async_writev_out;
	}&lt;/p&gt;
&lt;p&gt;Commit b7972092199f (&amp;#34;cifs: smbd: Retry on memory registration
failure&amp;#34;) changed both sides from -ENOBUFS to -EAGAIN in a single
patch, which puts the two shapes next to each other.&lt;/p&gt;
&lt;p&gt;Only the -EAGAIN return is reachable in practice, because
smb2_plain_req_init() calls smb2_reconnect() first and t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-2f7p-h662-999p</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media</title>
      <link>https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1</link>
      <description>&lt;p&gt;kernel-devel-7.2.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.2.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/opensuse-su-2026:11880-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-90125</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-90125</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: client: fix request buffer leak in smb2_new_read_req() smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between: 	rc = smb2_plain_req_init(SMB2_READ, io_parms-&amp;gt;tcon, server, 				 (void **) &amp;amp;req, total_len); 	if (rc) 		return rc; 	if (server == NULL) 		return -ECONNABORTED; 	[...] 		rdata-&amp;gt;mr = smbd_register_mr(server-&amp;gt;smbd_conn, 					     &amp;amp;rdata-&amp;gt;subreq.io_iter, 					     true, need_invalidate); 		if (!rdata-&amp;gt;mr) 			return -EAGAIN; On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does &amp;#39;goto out&amp;#39; on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case. The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning: 	wdata-&amp;gt;mr = smbd_register_mr(...); 	if (!wdata-&amp;gt;mr) { 		rc = -EAGAIN; 		goto async_writev_out; 	} Commit b7972092199f (&amp;#34;cifs: smbd: Retry on memory registration failure&amp;#34;) changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other. Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that alrea…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: client: fix request buffer leak in smb2_new_read_req() smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between: 	rc = smb2_plain_req_init(SMB2_READ, io_parms-&amp;gt;tcon, server, 				 (void **) &amp;amp;req, total_len); 	if (rc) 		return rc; 	if (server == NULL) 		return -ECONNABORTED; 	[...] 		rdata-&amp;gt;mr = smbd_register_mr(server-&amp;gt;smbd_conn, 					     &amp;amp;rdata-&amp;gt;subreq.io_iter, 					     true, need_invalidate); 		if (!rdata-&amp;gt;mr) 			return -EAGAIN; On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does &amp;#39;goto out&amp;#39; on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case. The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning: 	wdata-&amp;gt;mr = smbd_register_mr(...); 	if (!wdata-&amp;gt;mr) { 		rc = -EAGAIN; 		goto async_writev_out; 	} Commit b7972092199f (&amp;#34;cifs: smbd: Retry on memory registration failure&amp;#34;) changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other. Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that alrea…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-90125</guid>
    </item>
  </channel>
</rss>
