Slackware 14.2slackware-14.2

Thu Jun 30 20:26:57 UTC 2016
Slackware 14.2 x86_64 stable is released!

The long development cycle (the Linux community has lately been living in
"interesting times", as they say) is finally behind us, and we're proud to
announce the release of Slackware 14.2.  The new release brings many updates
and modern tools, has switched from udev to eudev (no systemd), and adds
well over a hundred new packages to the system.  Thanks to the team, the
upstream developers, the dedicated Slackware community, and everyone else
who pitched in to help make this release a reality.

The ISOs are off to be replicated, a 6 CD-ROM 32-bit set and a dual-sided
32-bit/64-bit x86/x86_64 DVD.  Please consider supporting the Slackware
project by picking up a copy from store.slackware.com.  We're taking
pre-orders now, and offer a discount if you sign up for a subscription.

Have fun!  :-)

1 files changed, 86 insertions, 0 deletions

diff --git a/source/ap/dmidecode/patches/0008-dmidecode-Use-read_file-to-read-the-DMI-table-from-s.patch b/source/ap/dmidecode/patches/0008-dmidecode-Use-read_file-to-read-the-DMI-table-from-s.patch
new file mode 100644
index 000000000..f0dc5aed5
--- /dev/null
+++ b/source/ap/dmidecode/patches/0008-dmidecode-Use-read_file-to-read-the-DMI-table-from-s.patch
@@ -0,0 +1,86 @@
+From 364055211b1956539c6a6268e111e244e1292c8c Mon Sep 17 00:00:00 2001
+From: Jean Delvare <jdelvare@suse.de>
+Date: Mon, 2 Nov 2015 09:45:31 +0100
+Subject: [PATCH 8/9] dmidecode: Use read_file() to read the DMI table from
+ sysfs
+
+We shouldn't use mem_chunk() to read the DMI table from sysfs. This
+will fail for SMBIOS v3 implementations which specify a maximum length
+for the table rather than its exact length. The kernel will trim the
+table to the actual length, so the DMI file will be shorter than the
+length announced in entry point.
+
+read_file() fits the bill in this case, as it deals with end of file
+nicely.
+
+This also helps with corrupted DMI tables, as the kernel will not
+export the part of the table that it wasn't able to parse, effectively
+trimming it.
+
+This fixes bug #46176:
+https://savannah.nongnu.org/bugs/?46176
+Unexpected end of file error
+---
+ CHANGELOG   |  3 +++
+ dmidecode.c | 29 +++++++++++++++++++++--------
+ 2 files changed, 24 insertions(+), 8 deletions(-)
+
+diff --git a/CHANGELOG b/CHANGELOG
+index 1e5437a..fcfc244 100644
+--- a/CHANGELOG
++++ b/CHANGELOG
+@@ -2,6 +2,9 @@
+ 
+ 	* dmidecode.c, util.c, util.h: Let read_file return the actual data
+ 	  size.
++	* dmidecode.c: Use read_file to read the DMI table from sysfs.
++	  This fixes Savannah bug #46176:
++	  https://savannah.nongnu.org/bugs/?46176
+ 
+ 2015-10-21  Xie XiuQi  <xiexiuqi@huawei.com>
+ 
+diff --git a/dmidecode.c b/dmidecode.c
+index a43cfd1..16d1823 100644
+--- a/dmidecode.c
++++ b/dmidecode.c
+@@ -4524,16 +4524,29 @@ static void dmi_table(off_t base, u32 len, u16 num, u16 ver, const char *devmem,
+ 		printf("\n");
+ 	}
+ 
+-	/*
+-	 * When we are reading the DMI table from sysfs, we want to print
+-	 * the address of the table (done above), but the offset of the
+-	 * data in the file is 0.  When reading from /dev/mem, the offset
+-	 * in the file is the address.
+-	 */
+ 	if (flags & FLAG_NO_FILE_OFFSET)
+-		base = 0;
++	{
++		/*
++		 * When reading from sysfs, the file may be shorter than
++		 * announced. For SMBIOS v3 this is expcted, as we only know
++		 * the maximum table size, not the actual table size. For older
++		 * implementations (and for SMBIOS v3 too), this would be the
++		 * result of the kernel truncating the table on parse error.
++		 */
++		size_t size = len;
++		buf = read_file(&size, devmem);
++		if (!(opt.flags & FLAG_QUIET) && num && size != (size_t)len)
++		{
++			printf("Wrong DMI structures length: %u bytes "
++				"announced, only %lu bytes available.\n",
++				len, (unsigned long)size);
++		}
++		len = size;
++	}
++	else
++		buf = mem_chunk(base, len, devmem);
+ 
+-	if ((buf = mem_chunk(base, len, devmem)) == NULL)
++	if (buf == NULL)
+ 	{
+ 		fprintf(stderr, "Table is unreachable, sorry."
+ #ifndef USE_MMAP
+-- 
+2.6.4
+