(In reply to Marcus Meissner from comment #0)
> rh#1485346
> 
> The acpi_ds_create_operands() function in drivers/acpi/acpica/dsutils.c
> in the Linux kernel through 4.12.9 does not flush the operand cache and
> causes a kernel stack dump, which allows local users to obtain
> sensitive information from kernel memory and bypass the KASLR
> protection mechanism (in the kernel through 4.9) via a crafted ACPI
> table.
> 
> Upstream fix:
> 
> https://github.com/acpica/acpica/pull/295/commits/
> 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732
> https://patchwork.kernel.org/patch/9919053/

After Seunghun Han's patch merged to kernel mainline, I will backport it to SLE.

ping

(In reply to Joey Lee from comment #3)
> (In reply to Marcus Meissner from comment #0)
> > rh#1485346
> > 
> > The acpi_ds_create_operands() function in drivers/acpi/acpica/dsutils.c
> > in the Linux kernel through 4.12.9 does not flush the operand cache and
> > causes a kernel stack dump, which allows local users to obtain
> > sensitive information from kernel memory and bypass the KASLR
> > protection mechanism (in the kernel through 4.9) via a crafted ACPI
> > table.
> > 
> > Upstream fix:
> > 
> > https://github.com/acpica/acpica/pull/295/commits/
> > 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732
> > https://patchwork.kernel.org/patch/9919053/
> 
> After Seunghun Han's patch merged to kernel mainline, I will backport it to
> SLE.

The patch did not merge to ACPICA or kernel yet. Currently I have no idea why does mainline delay it.

The patch seems forgotten.  Joey, could you try to ping upstream?  A CVE has been assigned, so this should be handled.

(In reply to Takashi Iwai from comment #7)
> The patch seems forgotten.  Joey, could you try to ping upstream?  A CVE has
> been assigned, so this should be handled.

I have add comment on the pull request on github:

https://github.com/acpica/acpica/pull/295

And, I also sent mail to devel@acpica.org for checking why this old patch not be merged.

(In reply to Joey Lee from comment #8)
> (In reply to Takashi Iwai from comment #7)
> > The patch seems forgotten.  Joey, could you try to ping upstream?  A CVE has
> > been assigned, so this should be handled.
> 
> I have add comment on the pull request on github:
> 
> https://github.com/acpica/acpica/pull/295
> 
> And, I also sent mail to devel@acpica.org for checking why this old patch
> not be merged.

Intel Robert Moore said they need to review it but not time yet:

https://lists.acpica.org/hyperkitty/list/devel@acpica.org/thread/CZX3DW4ZFEDCU76FCMGGWOPCZGDQSTBQ/

(In reply to Joey Lee from comment #9)
> (In reply to Joey Lee from comment #8)
> > (In reply to Takashi Iwai from comment #7)
> > > The patch seems forgotten.  Joey, could you try to ping upstream?  A CVE has
> > > been assigned, so this should be handled.
> > 
> > I have add comment on the pull request on github:
> > 
> > https://github.com/acpica/acpica/pull/295
> > 
> > And, I also sent mail to devel@acpica.org for checking why this old patch
> > not be merged.
> 
> Intel Robert Moore said they need to review it but not time yet:
> 
> https://lists.acpica.org/hyperkitty/list/devel@acpica.org/thread/
> CZX3DW4ZFEDCU76FCMGGWOPCZGDQSTBQ/

I filed a acpica bug to track it:
https://bugs.acpica.org/show_bug.cgi?id=1549

The "security" aspect of these fixes seems to be based on:

> kmem_cache_destroy() reports Acpi-Operand cache leak.
> ...
> This cache leak causes a security threat because an old kernel (<= 4.9) shows
> memory locations of kernel functions in stack dump. Some malicious users
> could use this information to neutralize kernel ASLR.

I can do same on SLE11 SP4 for instance by triggering OOM and then (as unprivileged user) read dmesg with stack dumps too.
Or is there anything more to this CVE?

(In reply to Michal Koutný from comment #11)
> The "security" aspect of these fixes seems to be based on:
> 
> > kmem_cache_destroy() reports Acpi-Operand cache leak.
> > ...
> > This cache leak causes a security threat because an old kernel (<= 4.9) shows
> > memory locations of kernel functions in stack dump. Some malicious users
> > could use this information to neutralize kernel ASLR.
> 
> I can do same on SLE11 SP4 for instance by triggering OOM and then (as
> unprivileged user) read dmesg with stack dumps too.
> Or is there anything more to this CVE?

KASLR has been introduced in 3.14 kernel and never backported to 11-sp4. We haven't enabled RANDOMIZE_BASE in 4.4 based kernels either. Only 4.12 based and newers have KASLR enabled AFAICS.

Thanks. So that rules out SLE11-SP4 and older.

I did some archaeology and found:
> eaf06b241b09 ("Restrict unprivileged access to kernel syslog") v2.6.37-rc2~55
> // CONFIG_SECURITY_DMESG_RESTRICT
> 637241a900cb ("kmsg: honor dmesg_restrict sysctl on /dev/kmsg") v3.10-rc6~21^2~24
> bfeda41d06d8 ("stacktrace, lockdep: Fix address, newline ugliness") v4.10-rc8~4^2
> ad67b74d2469 ("printk: hash addresses printed with %p") v4.15-rc2~27^2~2

And finally in kernel-source:
> d76eff24b061 ("Update config files: enable SECURITY_DMESG_RESTRICT (FATE#315175)") (since SLE12)

So even if I accept(*) the cache leak report is a security bug, it should not be exploitable in our kernels (ranging from: no KASLR, no readable dmesg to masked addresses).

All in all, Joey, if you want to pursue the ACPI bug, do so, otherwise, I'd return the bug back to sec-team as invalid..unaffected.

(*) This is IMO slippery slope and I'd rather argue this CVE is toothless.

Hi Michal,

(In reply to Michal Koutný from comment #13)
> Thanks. So that rules out SLE11-SP4 and older.
> 
> I did some archaeology and found:
> > eaf06b241b09 ("Restrict unprivileged access to kernel syslog") v2.6.37-rc2~55
> > // CONFIG_SECURITY_DMESG_RESTRICT
> > 637241a900cb ("kmsg: honor dmesg_restrict sysctl on /dev/kmsg") v3.10-rc6~21^2~24
> > bfeda41d06d8 ("stacktrace, lockdep: Fix address, newline ugliness") v4.10-rc8~4^2
> > ad67b74d2469 ("printk: hash addresses printed with %p") v4.15-rc2~27^2~2
> 
> And finally in kernel-source:
> > d76eff24b061 ("Update config files: enable SECURITY_DMESG_RESTRICT (FATE#315175)") (since SLE12)
> 
> So even if I accept(*) the cache leak report is a security bug, it should
> not be exploitable in our kernels (ranging from: no KASLR, no readable dmesg
> to masked addresses).
> 
> All in all, Joey, if you want to pursue the ACPI bug, do so, otherwise, I'd
> return the bug back to sec-team as invalid..unaffected.
> 
> (*) This is IMO slippery slope and I'd rather argue this CVE is toothless.

Thanks for your investigation. Honestly I don't know when upstream will accept the patch. Looks they don't think it's a serious problem. 

Could you please send this bug to security team?

Thanks a lot!

(In reply to Michal Koutný from comment #13)
[...] 
> All in all, Joey, if you want to pursue the ACPI bug, do so, otherwise, I'd
> return the bug back to sec-team as invalid..unaffected.

Completely agreed!

Reassigning back to security team, feel free to pick: a) we're not affected (due to KASLR xor leaky messages; or privileged dmesg(*)), b) invalid (we would soon go crazy hunting any such message).

(*) neglecting possible messages on local console