• D
    ipv6: sr: fix out-of-bounds read when setting HMAC data. · 4aff8239
    David Lebrun 提交于
    stable inclusion
    from stable-v5.10.143
    commit 076f2479fc5a15c4a970ca3b5e57d42ba09a31fa
    category: bugfix
    bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ASU6
    CVE: CVE-2023-2860
    
    Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=076f2479fc5a15c4a970ca3b5e57d42ba09a31fa
    
    --------------------------------
    
    [ Upstream commit 84a53580 ]
    
    The SRv6 layer allows defining HMAC data that can later be used to sign IPv6
    Segment Routing Headers. This configuration is realised via netlink through
    four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and
    SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual
    length of the SECRET attribute, it is possible to provide invalid combinations
    (e.g., secret = "", secretlen = 64). This case is not checked in the code and
    with an appropriately crafted netlink message, an out-of-bounds read of up
    to 64 bytes (max secret length) can occur past the skb end pointer and into
    skb_shared_info:
    
    Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208
    208		memcpy(hinfo->secret, secret, slen);
    (gdb) bt
     #0  seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208
     #1  0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600,
        extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>,
        family=<optimized out>) at net/netlink/genetlink.c:731
     #2  0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00,
        family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775
     #3  genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792
     #4  0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>)
        at net/netlink/af_netlink.c:2501
     #5  0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803
     #6  0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000)
        at net/netlink/af_netlink.c:1319
     #7  netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>)
        at net/netlink/af_netlink.c:1345
     #8  0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921
    ...
    (gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end
    $1 = 0xffff88800b1b76c0
    (gdb) p/x secret
    $2 = 0xffff88800b1b76c0
    (gdb) p slen
    $3 = 64 '@'
    
    The OOB data can then be read back from userspace by dumping HMAC state. This
    commit fixes this by ensuring SECRETLEN cannot exceed the actual length of
    SECRET.
    Reported-by: NLucas Leong <wmliang.tw@gmail.com>
    Tested: verified that EINVAL is correctly returned when secretlen > len(secret)
    Fixes: 4f4853dc ("ipv6: sr: implement API to control SR HMAC structure")
    Signed-off-by: NDavid Lebrun <dlebrun@google.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    Signed-off-by: NSasha Levin <sashal@kernel.org>
    Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
    4aff8239
seg6.c 10.2 KB