https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 09:05:20 +0000 https://vulnerability.circl.lu/vuln/cve-2023-53611 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ipmi_si: fix a memleak in try_smi_init()</p> <p>Kmemleak reported the following leak info in try_smi_init():</p> <p>unreferenced object 0xffff00018ecf9400 (size 1024): comm &#34;modprobe&#34;, pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [&lt;000000004ca5b312&gt;] __kmalloc+0x4b8/0x7b0 [&lt;00000000953b1072&gt;] try_smi_init+0x148/0x5dc [ipmi_si] [&lt;000000006460d325&gt;] 0xffff800081b10148 [&lt;0000000039206ea5&gt;] do_one_initcall+0x64/0x2a4 [&lt;00000000601399ce&gt;] do_init_module+0x50/0x300 [&lt;000000003c12ba3c&gt;] load_module+0x7a8/0x9e0 [&lt;00000000c246fffe&gt;] __se_sys_init_module+0x104/0x180 [&lt;00000000eea99093&gt;] __arm64_sys_init_module+0x24/0x30 [&lt;0000000021b1ef87&gt;] el0_svc_common.constprop.0+0x94/0x250 [&lt;0000000070f4f8b7&gt;] do_el0_svc+0x48/0xe0 [&lt;000000005a05337f&gt;] el0_svc+0x24/0x3c [&lt;000000005eb248d6&gt;] el0_sync_handler+0x160/0x164 [&lt;0000000030a59039&gt;] el0_sync+0x160/0x180</p> <p>The problem was that when an error occurred before handlers registration and after allocating `new_smi-&gt;si_sm`, the variable wouldn&#39;t be freed in the error handling afterwards since `shutdown_smi()` hadn&#39;t been registered yet. Fix it by adding a `kfree()` in the error handling path in `try_smi_init()`.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ipmi_si: fix a memleak in try_smi_init()</p> <p>Kmemleak reported the following leak info in try_smi_init():</p> <p>unreferenced object 0xffff00018ecf9400 (size 1024): comm &#34;modprobe&#34;, pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [&lt;000000004ca5b312&gt;] __kmalloc+0x4b8/0x7b0 [&lt;00000000953b1072&gt;] try_smi_init+0x148/0x5dc [ipmi_si] [&lt;000000006460d325&gt;] 0xffff800081b10148 [&lt;0000000039206ea5&gt;] do_one_initcall+0x64/0x2a4 [&lt;00000000601399ce&gt;] do_init_module+0x50/0x300 [&lt;000000003c12ba3c&gt;] load_module+0x7a8/0x9e0 [&lt;00000000c246fffe&gt;] __se_sys_init_module+0x104/0x180 [&lt;00000000eea99093&gt;] __arm64_sys_init_module+0x24/0x30 [&lt;0000000021b1ef87&gt;] el0_svc_common.constprop.0+0x94/0x250 [&lt;0000000070f4f8b7&gt;] do_el0_svc+0x48/0xe0 [&lt;000000005a05337f&gt;] el0_svc+0x24/0x3c [&lt;000000005eb248d6&gt;] el0_sync_handler+0x160/0x164 [&lt;0000000030a59039&gt;] el0_sync+0x160/0x180</p> <p>The problem was that when an error occurred before handlers registration and after allocating `new_smi-&gt;si_sm`, the variable wouldn&#39;t be freed in the error handling afterwards since `shutdown_smi()` hadn&#39;t been registered yet. Fix it by adding a `kfree()` in the error handling path in `try_smi_init()`.</p> https://vulnerability.circl.lu/vuln/cve-2023-53611