linux-kernel - [PATCH 0/3] Fix a misaligned load inside ptrace

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-next>] [day] [month] [year] [list]

Date:	Thu, 30 Apr 2015 21:19:54 -0700
From:	Palmer Dabbelt <palmer@...belt.com>
To:	vdavydov@...allels.com
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH 0/3] Fix a misaligned load inside ptrace_attach()

I ran across what I believe is a bug in some asm-generic code while
working on the RISC-V Linux port.  Essentially the problem is that
wait_on_bit() takes a void *, but then perfroms long-aligned
operation.  As far as I can tell, this bug could manifest on any other
architecture that doesn't support misaligned operations and uses this
particular asm-generic implementation.

The patch set is split into three parts:

* #1 fixes the bug by making task_struct.jobctl an unsigned long,
   which ensures wait_on_bit() always ends up with a long-aligned
   argument.

* #2 changes the prototype of wait_on_bit() and friends to take a
   "unsigned long *" instead of a "void *", with the intent of
   ensuring these problems don't happen again.

* #3 is a bit more intrusive: it goes and changes all uses of
   task_struct.jobctl from int to long.

I'm not sure if #3 has gone too far, but I think #1 and #2 are sane.
The cost is making task_struct larger on machines where
sizeof(long)>sizeof(int), but since it's so big already this isn't too
much cost.  I thought about making test_bit() perform byte-aligned
accesses to avoid this cost, but since there are very similar looking
atomic functions I thought that would be too odd.

--
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/