linux-kernel - Re: [linux-next-20130903] module: broken module versions?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Sep 2013 20:31:04 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	ak@...ux.intel.com, viro@...IV.linux.org.uk, geert@...ux-m68k.org,
	akpm@...ux-foundation.org
Cc:	dhowells@...hat.com, rusty@...tcorp.com.au,
	linux-kernel@...r.kernel.org, penguin-kernel@...ove.SAKURA.ne.jp
Subject: Re: [linux-next-20130903] module: broken module versions?

Hello.

This issue is not yet fixed as of linux-next-20130903. Without fixing this
issue, we would get 3.12-rc1 which cannot load several modules.

> I noticed that symbols which cause "disagrees about version of symbol" messages
> have crc == 0.

I tried further debugging but not yet successful.

---------- debug patch start ----------
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1192,6 +1192,9 @@ static int check_version(Elf_Shdr *sechdrs,
 		if (strcmp(versions[i].name, symname) != 0)
 			continue;
 
+		printk("Found %s checksum %lX vs module %lX\n",
+		       versions[i].name, maybe_relocated(*crc, crc_owner),
+		       versions[i].crc);
 		if (versions[i].crc == maybe_relocated(*crc, crc_owner))
 			return 1;
 		pr_debug("Found checksum %lX vs module %lX\n",
---------- debug patch end ----------

On x86_64, it shows

  Found sock_register checksum 0 vs module 0
  Found ns_capable checksum 0 vs module 0

and loading of ipv6.ko succeeds.

On x86_32, it shows

  Found sock_register checksum FF100000 vs module 0
  Found ns_capable checksum FF100000 vs module 0

and loading of ipv6.ko fails.

Thus, I came to assume that crc == 0 is the expected value but for some reason
crc == 0xFF100000 is recorded into kcrctab tables.



---------- debug patch start ----------
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -320,6 +320,11 @@ bool each_symbol_section(bool (*fn)(const struct symsearch *arr,
 #endif
 	};
 
+	static unsigned int i;
+	for (; i < __stop___ksymtab - __start___ksymtab; i++)
+		printk("%d crc(%s)=%lx\n", i, __start___ksymtab[i].name,
+		       __start___kcrctab[i]);
+
 	if (each_symbol_in_section(arr, ARRAY_SIZE(arr), NULL, fn, data))
 		return true;
 
---------- debug patch end ----------

On x86_64, "grep =0" shows

  236 crc(__symbol_put)=0
  784 crc(current_fs_time)=0
  810 crc(d_tmpfile)=0
  955 crc(do_sync_read)=0
  1093 crc(filp_close)=0
  1107 crc(finish_open)=0
  1183 crc(generic_getxattr)=0
  1207 crc(generic_write_sync)=0
  1237 crc(get_unmapped_area)=0
  1335 crc(in_group_p)=0
  1407 crc(inode_add_bytes)=0
  1495 crc(iov_shorten)=0
  1548 crc(iterate_fd)=0
  1815 crc(mnt_set_expiry)=0
  2038 crc(ns_capable)=0
  2102 crc(path_is_under)=0
  2405 crc(register_exec_domain)=0
  2506 crc(schedule_timeout)=0
  2911 crc(sock_register)=0
  2922 crc(softirq_work_list)=0
  2996 crc(sys_close)=0
  3022 crc(task_nice)=0
  3243 crc(vfs_fsync_range)=0
  3270 crc(vm_brk)=0

On x86_32, "grep =ff100000" shows

  244 crc(__symbol_put)=ff100000
  784 crc(current_fs_time)=ff100000
  810 crc(d_tmpfile)=ff100000
  967 crc(do_sync_read)=ff100000
  1108 crc(filp_close)=ff100000
  1122 crc(finish_open)=ff100000
  1198 crc(generic_getxattr)=ff100000
  1222 crc(generic_write_sync)=ff100000
  1253 crc(get_unmapped_area)=ff100000
  1351 crc(in_group_p)=ff100000
  1423 crc(inode_add_bytes)=ff100000
  1510 crc(iov_shorten)=ff100000
  1567 crc(iterate_fd)=ff100000
  1840 crc(mnt_set_expiry)=ff100000
  2061 crc(ns_capable)=ff100000
  2126 crc(path_is_under)=ff100000
  2432 crc(register_exec_domain)=ff100000
  2535 crc(schedule_timeout)=ff100000
  2940 crc(sock_register)=ff100000
  2951 crc(softirq_work_list)=ff100000
  3013 crc(sys_close)=ff100000
  3039 crc(task_nice)=ff100000
  3261 crc(vfs_fsync_range)=ff100000
  3288 crc(vm_brk)=ff100000

Module.symvers says that these symbols have crc == 0x00000000 and
kcrctab on x86_64 says that these symbols have crc == 0x00000000 but
kcrctab on x86_32 says that these symbols have crc == 0xff100000.

Prior to commit 5c019369 "syscalls.h: use gcc alias instead of assembler
aliases for syscalls", only crc(softirq_work_list)=ff100000 line was shown.



I don't know where 0xff100000 comes from, but this value is kconfig dependent
and this value might be by error introduced.

I also tried older kernels. As far as I tested (I might be wrong as this value
is kconfig dependent), it seems that 3.9 and later kernels show
crc(softirq_work_list)=ff100000 line while 3.8 and earlier kernels show
crc(softirq_work_list)=0 line. I'll try to bisect between 3.8 and 3.9 if this
change is by error introduced.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/