Hi again Ivan,
On Mon, 20 Apr 2015 13:19:46 +0300, Ivan Khoronzhuk wrote:
+ bin_attr_DMI.size = dmi_len;I just found that more work is needed here for the SMBIOS v3 entry
+ bin_attr_DMI.private = dmi_table;
+ ret = sysfs_create_bin_file(tables_kobj, &bin_attr_DMI);
+ if (!ret)
+ return 0;
point case. These entry points do not specify the exact length of the
table, but only its maximum. The real world sample I have access to
indeed specifies a maximum length of 6419 bytes, but the actual table
only spans over 2373 bytes. It is properly terminated with a type 127
DMI structure, so the kernel table parser ignores the garbage after it.
The garbage is however exported to user-space above.
I taught dmidecode to ignore the garbage, but there are two problem
left here. First problem is a waste of memory. Minor issue I suppose,
who cares about a few kilobytes these days.
Second problem is a security problem. We are leaking the contents of
physical memory to user-space. In my case it's filled with 0xffs so no
big deal. But what if actual data happens to be stored there? It
definitely shouldn't go to user-space.
So dmi_len needs to be trimmed to the actual table size before the
attribute above is created. I have an idea how this could be
implemented easily, let me give it a try.
Maybe we should trim the length for previous implementations, too.
There is no reason to walk past a type 127 structure anyway, ever.