<?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>Wed, 30 Sep 2026 22:35:54 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-49164 — powerpc/tm: Fix more userspace r13 corruption</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2022-49164</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;powerpc/tm: Fix more userspace r13 corruption&lt;/p&gt;
&lt;p&gt;Commit cf13435b730a (&amp;#34;powerpc/tm: Fix userspace r13 corruption&amp;#34;) fixes a
problem in treclaim where a SLB miss can occur on the
thread_struct-&amp;gt;ckpt_regs while SCRATCH0 is live with the saved user r13
value, clobbering it with the kernel r13 and ultimately resulting in
kernel r13 being stored in ckpt_regs.&lt;/p&gt;
&lt;p&gt;There is an equivalent problem in trechkpt where the user r13 value is
loaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss
could occur on ckpt_regs accesses after that, which will result in r13
being clobbered with a kernel value and that will get recheckpointed and
then restored to user registers.&lt;/p&gt;
&lt;p&gt;The same memory page is accessed right before this critical window where
a SLB miss could cause corruption, so hitting the bug requires the SLB
entry be removed within a small window of instructions, which is
possible if a SLB related MCE hits there. PAPR also permits the
hypervisor to discard this SLB entry (because slb_shadow-&amp;gt;persistent is
only set to SLB_NUM_BOLTED) although it&amp;#39;s not known whether any
implementations would do this (KVM does not). So this is an extremely
unlikely bug, only found by inspection.&lt;/p&gt;
&lt;p&gt;Fix this by also storing user r13 in a temporary location on the kernel
stack and don&amp;#39;t change the r13 register from kernel r13 until the RI=0
critical section that does not fault.&lt;/p&gt;
&lt;p&gt;The SCRATCH0 change is not strictly part of the fix, it&amp;#39;…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;powerpc/tm: Fix more userspace r13 corruption&lt;/p&gt;
&lt;p&gt;Commit cf13435b730a (&amp;#34;powerpc/tm: Fix userspace r13 corruption&amp;#34;) fixes a
problem in treclaim where a SLB miss can occur on the
thread_struct-&amp;gt;ckpt_regs while SCRATCH0 is live with the saved user r13
value, clobbering it with the kernel r13 and ultimately resulting in
kernel r13 being stored in ckpt_regs.&lt;/p&gt;
&lt;p&gt;There is an equivalent problem in trechkpt where the user r13 value is
loaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss
could occur on ckpt_regs accesses after that, which will result in r13
being clobbered with a kernel value and that will get recheckpointed and
then restored to user registers.&lt;/p&gt;
&lt;p&gt;The same memory page is accessed right before this critical window where
a SLB miss could cause corruption, so hitting the bug requires the SLB
entry be removed within a small window of instructions, which is
possible if a SLB related MCE hits there. PAPR also permits the
hypervisor to discard this SLB entry (because slb_shadow-&amp;gt;persistent is
only set to SLB_NUM_BOLTED) although it&amp;#39;s not known whether any
implementations would do this (KVM does not). So this is an extremely
unlikely bug, only found by inspection.&lt;/p&gt;
&lt;p&gt;Fix this by also storing user r13 in a temporary location on the kernel
stack and don&amp;#39;t change the r13 register from kernel r13 until the RI=0
critical section that does not fault.&lt;/p&gt;
&lt;p&gt;The SCRATCH0 change is not strictly part of the fix, it&amp;#39;…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2022-49164</guid>
    </item>
  </channel>
</rss>
