<?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>Tue, 29 Sep 2026 16:52:06 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-49196 — powerpc/pseries: Fix use after free in remove_phb_dynamic()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2022-49196</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/pseries: Fix use after free in remove_phb_dynamic()&lt;/p&gt;
&lt;p&gt;In remove_phb_dynamic() we use &amp;amp;phb-&amp;gt;io_resource, after we&amp;#39;ve called
device_unregister(&amp;amp;host_bridge-&amp;gt;dev). But the unregister may have freed
phb, because pcibios_free_controller_deferred() is the release function
for the host_bridge.&lt;/p&gt;
&lt;p&gt;If there are no outstanding references when we call device_unregister()
then phb will be freed out from under us.&lt;/p&gt;
&lt;p&gt;This has gone mainly unnoticed, but with slub_debug and page_poison
enabled it can lead to a crash:&lt;/p&gt;
&lt;p&gt;PID: 7574   TASK: c0000000d492cb80  CPU: 13  COMMAND: &amp;#34;drmgr&amp;#34;
   #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc
   #1 [c0000000e4f075d0] oops_end at c000000000029608
   #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4
   #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8
   #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30
   Data SLB Access [380] exception frame:
   R0:  c000000000167250    R1:  c0000000e4f07a00    R2:  c000000002a46100
   R3:  c000000002b39ce8    R4:  00000000000000c0    R5:  00000000000000a9
   R6:  3894674d000000c0    R7:  0000000000000000    R8:  00000000000000ff
   R9:  0000000000000100    R10: 6b6b6b6b6b6b6b6b    R11: 0000000000008000
   R12: c00000000023da80    R13: c0000009ffd38b00    R14: 0000000000000000
   R15: 000000011c87f0f0    R16: 0000000000000006    R17: 0000000000000003
   R18: 0000000000000002    R19: 0000000000000004    R…&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/pseries: Fix use after free in remove_phb_dynamic()&lt;/p&gt;
&lt;p&gt;In remove_phb_dynamic() we use &amp;amp;phb-&amp;gt;io_resource, after we&amp;#39;ve called
device_unregister(&amp;amp;host_bridge-&amp;gt;dev). But the unregister may have freed
phb, because pcibios_free_controller_deferred() is the release function
for the host_bridge.&lt;/p&gt;
&lt;p&gt;If there are no outstanding references when we call device_unregister()
then phb will be freed out from under us.&lt;/p&gt;
&lt;p&gt;This has gone mainly unnoticed, but with slub_debug and page_poison
enabled it can lead to a crash:&lt;/p&gt;
&lt;p&gt;PID: 7574   TASK: c0000000d492cb80  CPU: 13  COMMAND: &amp;#34;drmgr&amp;#34;
   #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc
   #1 [c0000000e4f075d0] oops_end at c000000000029608
   #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4
   #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8
   #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30
   Data SLB Access [380] exception frame:
   R0:  c000000000167250    R1:  c0000000e4f07a00    R2:  c000000002a46100
   R3:  c000000002b39ce8    R4:  00000000000000c0    R5:  00000000000000a9
   R6:  3894674d000000c0    R7:  0000000000000000    R8:  00000000000000ff
   R9:  0000000000000100    R10: 6b6b6b6b6b6b6b6b    R11: 0000000000008000
   R12: c00000000023da80    R13: c0000009ffd38b00    R14: 0000000000000000
   R15: 000000011c87f0f0    R16: 0000000000000006    R17: 0000000000000003
   R18: 0000000000000002    R19: 0000000000000004    R…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2022-49196</guid>
    </item>
  </channel>
</rss>
