When dump_one_state() returns an error, e.g. because of a too small
buffer to dump the whole xfrm state, xfrm_state_netlink() returns NULL
instead of an error pointer. But its callers expect an error pointer
and therefore continue to operate on a NULL skbuff.
This could lead to a privilege escalation (execution of user code in
kernel context) if the attacker has CAP_NET_ADMIN and is able to map
address 0.
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Krause <redacted>
---
A test case can be provided on request.
net/xfrm/xfrm_user.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
On Thu, Sep 13, 2012 at 11:41:26PM +0200, Mathias Krause wrote:
When dump_one_state() returns an error, e.g. because of a too small
buffer to dump the whole xfrm state, xfrm_state_netlink() returns NULL
instead of an error pointer. But its callers expect an error pointer
and therefore continue to operate on a NULL skbuff.
This could lead to a privilege escalation (execution of user code in
kernel context) if the attacker has CAP_NET_ADMIN and is able to map
address 0.
Or it simply crashes with a NULL pointer dereference.
On Mon, Sep 17, 2012 at 9:16 AM, Steffen Klassert
[off-list ref] wrote:
On Thu, Sep 13, 2012 at 11:41:26PM +0200, Mathias Krause wrote:
quoted
When dump_one_state() returns an error, e.g. because of a too small
buffer to dump the whole xfrm state, xfrm_state_netlink() returns NULL
instead of an error pointer. But its callers expect an error pointer
and therefore continue to operate on a NULL skbuff.
This could lead to a privilege escalation (execution of user code in
kernel context) if the attacker has CAP_NET_ADMIN and is able to map
address 0.
Or it simply crashes with a NULL pointer dereference.
..while holding the xfrm_cfg_mutex, therefore effectively disabling
the XFRM netlink interface. So it's at least a DOS in that case ;)
Regards,
Mathias
On Thu, Sep 13, 2012 at 11:41:26PM +0200, Mathias Krause wrote:
quoted
When dump_one_state() returns an error, e.g. because of a too small
buffer to dump the whole xfrm state, xfrm_state_netlink() returns NULL
instead of an error pointer. But its callers expect an error pointer
and therefore continue to operate on a NULL skbuff.
This could lead to a privilege escalation (execution of user code in
kernel context) if the attacker has CAP_NET_ADMIN and is able to map
address 0.
Or it simply crashes with a NULL pointer dereference.
Applied, and queued up for -stable.
Please do not CC: stable explicitly in your patch submissions,
I removed it from the patch.
Instead, ask me to queue the patch up for -stable. We handle stable
submissed via a patch queue which I maintain at:
http://patchwork.ozlabs.org/user/bundle/2566/?state=*
so that I can let patches cook in Linus's tree for a length of
time of my choosing, rather than having bug fixes automatically
propagate the moment it hits Linus's tree.
Thanks.