Le Tuesday 21 April 2015 à 19:03 +0300, Ivan.khoronzhuk a écrit : > On 21.04.15 18:36, Jean Delvare wrote: > > I just found that more work is needed here for the SMBIOS v3 entry > > 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. > > > > It can happen of-cause, I've also thought about that sometime ago, > but forget...). > I've sent the updated series already. Got it, reviewed and ready to push upstream. I'll do so as soon as I'm done with other duties. > Let me know when your fix will be ready and I will re-base the > series if it has conflicts. Don't worry, I'm quite good at manual conflict resolution :) Thanks, -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
