Bug 982761 - ip xfrm aborts when trying to add new state
ip xfrm aborts when trying to add new state
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iproute (Show other bugs)
7.0
All Linux
high Severity high
: beta
: ---
Assigned To: Petr Šabata
Ondrej Moriš
: Regression, SELinux
Depends On:
Blocks: RHEL7CCC
  Show dependency treegraph
 
Reported: 2013-07-09 15:57 EDT by Miroslav Vadkerti
Modified: 2014-06-17 20:33 EDT (History)
8 users (show)

See Also:
Fixed In Version: iproute-3.10.0-2.el7
Doc Type: Bug Fix
Doc Text:
No documentation required.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 07:20:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
coredump from the reproducer (440.00 KB, application/x-core)
2013-07-09 16:08 EDT, Miroslav Vadkerti
no flags Details

  None (edit)
Description Miroslav Vadkerti 2013-07-09 15:57:20 EDT
Description of problem:
ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 ctx staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 auth md5 0123456789012345
*** buffer overflow detected ***: ip terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x36e030c9d7]
/lib64/libc.so.6[0x36e030aba0]
/lib64/libc.so.6[0x36e0309f3b]
ip[0x421b9e]
ip(do_xfrm_state+0x7a1)[0x422711]
ip[0x406474]
ip(main+0x292)[0x406062]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x36e0221b75]
ip[0x40632d]
======= Memory map: ========
00400000-00442000 r-xp 00000000 fd:01 201973755                          /usr/sbin/ip
00642000-00643000 r--p 00042000 fd:01 201973755                          /usr/sbin/ip
00643000-00647000 rw-p 00043000 fd:01 201973755                          /usr/sbin/ip
00647000-0064c000 rw-p 00000000 00:00 0
00846000-00848000 rw-p 00046000 fd:01 201973755                          /usr/sbin/ip
00d74000-00d95000 rw-p 00000000 00:00 0                                  [heap]
36dfe00000-36dfe21000 r-xp 00000000 fd:01 134379866                      /usr/lib64/ld-2.17.so
36e0020000-36e0021000 r--p 00020000 fd:01 134379866                      /usr/lib64/ld-2.17.so
36e0021000-36e0022000 rw-p 00021000 fd:01 134379866                      /usr/lib64/ld-2.17.so
36e0022000-36e0023000 rw-p 00000000 00:00 0
36e0200000-36e03b5000 r-xp 00000000 fd:01 134379992                      /usr/lib64/libc-2.17.so
36e03b5000-36e05b5000 ---p 001b5000 fd:01 134379992                      /usr/lib64/libc-2.17.so
36e05b5000-36e05b9000 r--p 001b5000 fd:01 134379992                      /usr/lib64/libc-2.17.so
36e05b9000-36e05bb000 rw-p 001b9000 fd:01 134379992                      /usr/lib64/libc-2.17.so
36e05bb000-36e05c0000 rw-p 00000000 00:00 0
36e0600000-36e0603000 r-xp 00000000 fd:01 134412291                      /usr/lib64/libdl-2.17.so
36e0603000-36e0802000 ---p 00003000 fd:01 134412291                      /usr/lib64/libdl-2.17.so
36e0802000-36e0803000 r--p 00002000 fd:01 134412291                      /usr/lib64/libdl-2.17.so
36e0803000-36e0804000 rw-p 00003000 fd:01 134412291                      /usr/lib64/libdl-2.17.so
36e2a00000-36e2a15000 r-xp 00000000 fd:01 134412819                      /usr/lib64/libgcc_s-4.8.1-20130612.so.1
36e2a15000-36e2c14000 ---p 00015000 fd:01 134412819                      /usr/lib64/libgcc_s-4.8.1-20130612.so.1
36e2c14000-36e2c15000 r--p 00014000 fd:01 134412819                      /usr/lib64/libgcc_s-4.8.1-20130612.so.1
36e2c15000-36e2c16000 rw-p 00015000 fd:01 134412819                      /usr/lib64/libgcc_s-4.8.1-20130612.so.1
7fb569e55000-7fb569e58000 rw-p 00000000 00:00 0
7fb569e6e000-7fb569e70000 rw-p 00000000 00:00 0
7fffb57a3000-7fffb57c4000 rw-p 00000000 00:00 0                          [stack]
7fffb57fe000-7fffb5800000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)

Version-Release number of selected component (if applicable):
iproute-3.9.0-1.el7

How reproducible:
100%

Steps to Reproduce:
# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 ctx staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 auth md5 0123456789012345

Actual results:
Segfault

Expected results:
State added

Additional info:
This is a regression from RHEL6
Comment 2 Miroslav Vadkerti 2013-07-09 16:08:04 EDT
Created attachment 771202 [details]
coredump from the reproducer
Comment 4 Petr Šabata 2013-07-17 10:05:05 EDT
A fix pushed in iproute-3.10.0-2.el7
Comment 5 Ondrej Moriš 2013-08-23 10:30:26 EDT
Petr, unfortunately the fix seems not work correctly. Even though there is no segfault with iproute-3.10.0-2.1.el7, no SA is being added into kernel:

# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 ctx staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 auth md5 012345678901234 ; ip xfrm state
#

(see? no SA)

It should work as follows:

# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 ctx staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 auth md5 012345678901234 ; ip xfrm state
src 10.0.0.2 dst 10.0.0.1
        proto ah spi 0x12345678 reqid 0 mode transport
        replay-window 0 
        auth hmac(md5) 0x303132333435363738393031323334
        sel src 0.0.0.0/0 dst 0.0.0.0/0 
        security context staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 

Switching back to assigned.
Comment 7 Petr Pisar 2013-10-01 08:48:21 EDT
This report is for segfault. This has been fixed. Moving back to ON_QA.

If you think the security associations are not set or listed properly, file a new bug report.

(I want to remark that the reproducer you provided does not work anywhere (RHEL-6, F21, upstream iproute sources).)
Comment 8 Sohny 2013-10-01 13:25:44 EDT
I also faced the same issue running the ipv6 TAHI tests on Fedora 19 . I debugged and found the issue to be in iproute2 with xfrm add command.
This is more a SIGABRT issue than a SIGSEGV when the strncpy's latest implementation causes it to spew buffer overflow detection failure with _strncpy_chk. 
I was able to fix this with strnlen+1 fix but there is a different fix available upstream : 
http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=99500b56d94dfa735a3d088fdbdde6c0c2638e78
Comment 9 Petr Pisar 2013-10-02 02:04:32 EDT
Yes, the fix is different, but effectively equal.

The reason why the compiler complained and glibc aborted is that: 

struct xfrm_algo {
    char        alg_name[64];
    unsigned int    alg_key_len;    /* in bits */
    char        alg_key[0];
};

struct {
    union {
        struct xfrm_algo alg;
        struct xfrm_algo_aead aead;
        struct xfrm_algo_auth auth;
    } u;
    char buf[XFRM_ALGO_KEY_BUF_SIZE];
} alg = {};

buf = alg.u.alg.alg_key;

xfrm_algo_parse((void *)&alg, type, name, key,
                   buf, sizeof(alg.buf));

xfrm_algo_parse() did strncpy(buf, key, len). The xfrm_algo.alg_key is just a pointer that obviously should be set to alg.buf, but it isn't. At least I cannot find where it is done so. Thus glibc aborted. GCC warned just because xfrm_algo.alg_key is declared char[0].

I think the write to wrong address is still there. Upstream just replaced strncpy() with memcpy(). It maybe satisfies GCC, but does not fix the the real problem. That could explain why I cannot set the SA. Or am I missing something?

Sohny, does the latest upstream source work for you? It does not for me. Or do I have to load some kernel module manually?
Comment 10 Petr Pisar 2013-10-02 02:30:50 EDT
(In reply to Petr Pisar from comment #7)
> 
> If you think the security associations are not set or listed properly, file
> a new bug report.
> 
Adding SA with SELinux context does not work only. I don't know how is responsible for translating the SELinux symbolic names into kernel internal identifiers. Ondrej, do you the labels exist in your system (staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023)?
Comment 11 Ondrej Moriš 2013-10-02 08:58:34 EDT
(In reply to Petr Pisar from comment #10)
> (In reply to Petr Pisar from comment #7)
> > 
> > If you think the security associations are not set or listed properly, file
> > a new bug report.
> > 
> Adding SA with SELinux context does not work only. I don't know how is
> responsible for translating the SELinux symbolic names into kernel internal
> identifiers. Ondrej, do you the labels exist in your system
> (staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023)?

That is strange, with iproute-3.10.0-2.1.el7.x86_64, kernel-3.10.0-15.el7.x86_64 and selinux-policy-3.12.1-73.el7.noarch it works:

# ip xfrm state
# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 ctx staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 auth md5 0123456789012345
# ip xfrm state
src 10.0.0.2 dst 10.0.0.1
        proto ah spi 0x12345678 reqid 0 mode transport
        replay-window 0 
        auth-trunc hmac(md5) 0x30313233343536373839303132333435 96
        sel src 0.0.0.0/0 dst 0.0.0.0/0 
        security context staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 
# ip xfrm state flush
# ip xfrm state
#

The problem was probably in kernel, I cannot downgrade right now. Petr could you confirm that with the aforementioned kernel it works?
Comment 12 Petr Pisar 2013-10-02 10:32:59 EDT
I tried latest packages (newer than your) and it does not work. Even if I replace your context with domains I have on the system (staff_u:staff_r:staff_t:s0-s15:c0.c1023). I will try to downgrade later, but I guess there is something that has to be enabled we miss.
Comment 13 Marcela Mašláňová 2013-10-02 10:53:59 EDT
Mirek,
would you know what can be wrong from a quick look? Some SElinux changes, some conditional loading of modules...
Comment 14 Sohny 2013-10-04 08:27:19 EDT
> Sohny, does the latest upstream source work for you? It does not for me. Or
> do I have to load some kernel module manually?

Well with F19 i get the following output. So i think it works

[root@llm128 ~]# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi 0x12345678 auth md5 12
[root@llm128 ~]# ip xfrm state
src 10.0.0.2 dst 10.0.0.1
	proto ah spi 0x12345678 reqid 0 mode transport
	replay-window 0 
	auth-trunc hmac(md5) 0x3132 96
	sel src 0.0.0.0/0 dst 0.0.0.0/0 
[root@llm128 ~]# uname -a
Linux llm128.in.ibm.com 3.9.5-301.fc19.x86_64 #1 SMP Tue Jun 11 19:39:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 15 Petr Pisar 2013-10-07 02:22:47 EDT
(In reply to Sohny from comment #14)
> > Sohny, does the latest upstream source work for you? It does not for me. Or
> > do I have to load some kernel module manually?
> 
> Well with F19 i get the following output. So i think it works
> 
> [root@llm128 ~]# ip xfrm state add src 10.0.0.2 dst 10.0.0.1 proto ah spi
> 0x12345678 auth md5 12

I've already narrowed the non-working scenario. It does not works only with the SELinux labeling in F19. I.e. if the ctx argument is specified.
Comment 17 Miroslav Vadkerti 2013-11-14 05:14:45 EST
Giving this for retesting to Ondrej. The original reported case should be tested explicitly by execution of tp/ipsec* tests on RHEL7 (that is done continuously).
Comment 18 Ondrej Moriš 2013-11-14 06:49:59 EST
I am confirming that on RHEL-7.0-20131018 it works as described in Comment #11. Petr - are you sure you have MLS selinux policy? Obviously you can use ctx only in MLS, otherwise it makes no sense. Base on Comment #11, #14 and #15 I consider this one to be verified.
Comment 19 Ondrej Moriš 2013-11-14 06:54:31 EST
Setting qe_test_coverage+ since we are testing this issue periodically as a part of Common Criteria testing as suggested in Comment #17.
Comment 20 Petr Pisar 2013-11-14 08:05:28 EST
(In reply to Ondrej Moriš from comment #18)
>  Petr - are you sure you have MLS selinux policy? Obviously you can use
> ctx only in MLS, otherwise it makes no sense.

That's it. I forgot completely on the policy type. You are right.

If I switch to the MLS, then attempt to add the IPSec policy with unresolvable context results into no error message or exit code but no policy is added. Attempt to add the policy with resolvable context results in success and I can see the new IPSec policy in the security policy dump incuding the SELinux context.

(I get SELinux denial in enforcing mode, so I had to switch into permissive mode, but that's another problem or misconfiguration of my system.)

So I also confirm it works within MLS SELlinux policy loaded.
Comment 21 Ludek Smid 2014-06-13 07:20:10 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.