Al Viro discovered in net/ipv[46]/raw.c raw_sendmsg() we have if (!inet->hdrincl) raw_probe_proto_opt(&fl, msg); err = ip_route_output_flow(&rt, &fl, sk, !(msg-..... So call sendmsg with sk->sk_protocol == IPPROTO_ICMP, msg->msg_iovlen = 1 and msg->msg_iov[0].iov_base pointing to kernel space (.iov_len > 1). Then in raw_probe_proto_opt() we have type == msg->msg_iov[0].iov_base code == msg->msg_iov[0].iov_base + 1 when we hit get_user(fl->fl_icmp_type, type); __get_user(fl->fl_icmp_code, code); Note that failure of the first call is ignored and we happily do the second call, an unchecked __get_user() which generates a memory read on the arbitrary user-supplied address. sendmsg() will fail if iovec points to kernel memory, but it may be possible to trick ip_route_output_flow() into returning an error depending on the value of fl->fl_icmp_code. Iff we can do that, the attacker can obtain information about the value read from arbitrary kernel address by looking at the error returned by sendmsg(2). On some architectures (including x86) a 16 bit read at a user-supplied address could access iomem (no separate mmu context) and therefore mess with hardware state leading to a DoS. "A local unprivileged user may be able to use this flaw to leak information about the contents of kernel memory, or on some architectures cause a denial of service by manipulating hardware state"
Created attachment 118139 [details] Proposed patch
Notified security, vendor-sec. Embargo set for one week, 20050907:12
Public as at 20050909 by commit to git; removing embargo
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-514.html
Created attachment 1522388 [details] fuse-mount-log