<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/net/ipv6/seg6.c, branch linux-6.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2022-09-08T16:38:30Z</updated>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2022-09-08T16:38:30Z</updated>
<author>
<name>Paolo Abeni</name>
<email>pabeni@redhat.com</email>
</author>
<published>2022-09-08T16:34:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9f8f1933dce555d3c246f447f54fca8de8889da9'/>
<id>urn:sha1:9f8f1933dce555d3c246f447f54fca8de8889da9</id>
<content type='text'>
drivers/net/ethernet/freescale/fec.h
  7d650df99d52 ("net: fec: add pm_qos support on imx6q platform")
  40c79ce13b03 ("net: fec: add stop mode support for imx8 platform")

Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>ipv6: sr: fix out-of-bounds read when setting HMAC data.</title>
<updated>2022-09-05T09:33:34Z</updated>
<author>
<name>David Lebrun</name>
<email>dlebrun@google.com</email>
</author>
<published>2022-09-02T09:45:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=84a53580c5d2138c7361c7c3eea5b31827e63b35'/>
<id>urn:sha1:84a53580c5d2138c7361c7c3eea5b31827e63b35</id>
<content type='text'>
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=&lt;optimized out&gt;, info=&lt;optimized out&gt;) at net/ipv6/seg6.c:208
208		memcpy(hinfo-&gt;secret, secret, slen);
(gdb) bt
 #0  seg6_genl_sethmac (skb=&lt;optimized out&gt;, info=&lt;optimized out&gt;) 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 &lt;init_net&gt;, family=&lt;optimized out&gt;,
    family=&lt;optimized out&gt;) at net/netlink/genetlink.c:731
 #2  0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00,
    family=0xffffffff82fef6c0 &lt;seg6_genl_family&gt;) 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 &lt;genl_rcv_msg&gt;)
    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=&lt;optimized out&gt;)
    at net/netlink/af_netlink.c:1345
 #8  0xffffffff81dff9a4 in netlink_sendmsg (sock=&lt;optimized out&gt;, msg=0xffffc90000ba7e48, len=&lt;optimized out&gt;) at net/netlink/af_netlink.c:1921
...
(gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)-&gt;head + ((struct sk_buff *)0xffff88800b1f9f00)-&gt;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: Lucas Leong &lt;wmliang.tw@gmail.com&gt;
Tested: verified that EINVAL is correctly returned when secretlen &gt; len(secret)
Fixes: 4f4853dc1c9c1 ("ipv6: sr: implement API to control SR HMAC structure")
Signed-off-by: David Lebrun &lt;dlebrun@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>genetlink: start to validate reserved header bytes</title>
<updated>2022-08-29T11:47:15Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-08-25T00:18:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9c5d03d362519f36cd551aec596388f895c93d2d'/>
<id>urn:sha1:9c5d03d362519f36cd551aec596388f895c93d2d</id>
<content type='text'>
We had historically not checked that genlmsghdr.reserved
is 0 on input which prevents us from using those precious
bytes in the future.

One use case would be to extend the cmd field, which is
currently just 8 bits wide and 256 is not a lot of commands
for some core families.

To make sure that new families do the right thing by default
put the onus of opting out of validation on existing families.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Acked-by: Paul Moore &lt;paul@paul-moore.com&gt; (NetLabel)
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>icmp: ICMPV6: Examine invoking packet for Segment Route Headers.</title>
<updated>2022-01-04T12:17:35Z</updated>
<author>
<name>Andrew Lunn</name>
<email>andrew@lunn.ch</email>
</author>
<published>2022-01-03T17:11:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e41294408c56c68ea0f269d757527bf33b39118a'/>
<id>urn:sha1:e41294408c56c68ea0f269d757527bf33b39118a</id>
<content type='text'>
RFC8754 says:

ICMP error packets generated within the SR domain are sent to source
nodes within the SR domain.  The invoking packet in the ICMP error
message may contain an SRH.  Since the destination address of a packet
with an SRH changes as each segment is processed, it may not be the
destination used by the socket or application that generated the
invoking packet.

For the source of an invoking packet to process the ICMP error
message, the ultimate destination address of the IPv6 header may be
required.  The following logic is used to determine the destination
address for use by protocol-error handlers.

*  Walk all extension headers of the invoking IPv6 packet to the
   routing extension header preceding the upper-layer header.

   -  If routing header is type 4 Segment Routing Header (SRH)

      o  The SID at Segment List[0] may be used as the destination
         address of the invoking packet.

Mangle the skb so the network header points to the invoking packet
inside the ICMP packet. The seg6 helpers can then be used on the skb
to find any segment routing headers. If found, mark this fact in the
IPv6 control block of the skb, and store the offset into the packet of
the SRH. Then restore the skb back to its old state.

Signed-off-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Reviewed-by: Willem de Bruijn &lt;willemb@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>seg6: export get_srh() for ICMP handling</title>
<updated>2022-01-04T12:17:35Z</updated>
<author>
<name>Andrew Lunn</name>
<email>andrew@lunn.ch</email>
</author>
<published>2022-01-03T17:11:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fa55a7d745de2d10489295b0674a403e2a5d490d'/>
<id>urn:sha1:fa55a7d745de2d10489295b0674a403e2a5d490d</id>
<content type='text'>
An ICMP error message can contain in its message body part of an IPv6
packet which invoked the error. Such a packet might contain a segment
router header. Export get_srh() so the ICMP code can make use of it.

Since his changes the scope of the function from local to global, add
the seg6_ prefix to keep the namespace clean. And move it into seg6.c
so it is always available, not just when IPV6_SEG6_LWTUNNEL is
enabled.

Signed-off-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Reviewed-by: Willem de Bruijn &lt;willemb@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net:ipv6:Remove unneeded semicolon</title>
<updated>2021-11-03T11:18:46Z</updated>
<author>
<name>Zhang Mingyu</name>
<email>zhang.mingyu@zte.com.cn</email>
</author>
<published>2021-11-03T06:46:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=acaea0d5a63406c052444ad3a7cb54241adaf805'/>
<id>urn:sha1:acaea0d5a63406c052444ad3a7cb54241adaf805</id>
<content type='text'>
Eliminate the following coccinelle check warning:
net/ipv6/seg6.c:381:2-3

Reported-by: Zeal Robot &lt;zealci@zte.com.cn&gt;
Signed-off-by: Zhang Mingyu &lt;zhang.mingyu@zte.com.cn&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: ipv6: fix use after free of struct seg6_pernet_data</title>
<updated>2021-10-04T12:40:19Z</updated>
<author>
<name>MichelleJin</name>
<email>shjy180909@gmail.com</email>
</author>
<published>2021-10-02T22:33:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=23b08260481ca552180130bbef0f3a60df4c092e'/>
<id>urn:sha1:23b08260481ca552180130bbef0f3a60df4c092e</id>
<content type='text'>
sdata-&gt;tun_src should be freed before sdata is freed
because sdata-&gt;tun_src is allocated after sdata allocation.
So, kfree(sdata) and kfree(rcu_dereference_raw(sdata-&gt;tun_src)) are
changed code order.

Fixes: f04ed7d277e8 ("net: ipv6: check return value of rhashtable_init")

Signed-off-by: MichelleJin &lt;shjy180909@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: ipv6: check return value of rhashtable_init</title>
<updated>2021-09-28T11:59:24Z</updated>
<author>
<name>MichelleJin</name>
<email>shjy180909@gmail.com</email>
</author>
<published>2021-09-27T03:34:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f04ed7d277e842af9934b71b529341d1ba31a9c1'/>
<id>urn:sha1:f04ed7d277e842af9934b71b529341d1ba31a9c1</id>
<content type='text'>
When rhashtable_init() fails, it returns -EINVAL.
However, since error return value of rhashtable_init is not checked,
it can cause use of uninitialized pointers.
So, fix unhandled errors of rhashtable_init.

Signed-off-by: MichelleJin &lt;shjy180909@gmail.com&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Remove redundant assignment to err</title>
<updated>2021-04-29T22:34:15Z</updated>
<author>
<name>Yang Li</name>
<email>yang.lee@linux.alibaba.com</email>
</author>
<published>2021-04-29T01:32:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1a70f6597d5f8abf6cea8e2df213740a18746194'/>
<id>urn:sha1:1a70f6597d5f8abf6cea8e2df213740a18746194</id>
<content type='text'>
Variable 'err' is set to -ENOMEM but this value is never read as it is
overwritten with a new value later on, hence the 'If statements' and
assignments are redundantand and can be removed.

Cleans up the following clang-analyzer warning:

net/ipv6/seg6.c:126:4: warning: Value stored to 'err' is never read
[clang-analyzer-deadcode.DeadStores]

Reported-by: Abaci Robot &lt;abaci@linux.alibaba.com&gt;
Signed-off-by: Yang Li &lt;yang.lee@linux.alibaba.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>seg6: fix seg6_validate_srh() to avoid slab-out-of-bounds</title>
<updated>2020-06-04T22:39:32Z</updated>
<author>
<name>Ahmed Abdelsalam</name>
<email>ahabdels@gmail.com</email>
</author>
<published>2020-06-03T06:54:42Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bb986a50421a11bf31a81afb15b9b8f45a4a3a11'/>
<id>urn:sha1:bb986a50421a11bf31a81afb15b9b8f45a4a3a11</id>
<content type='text'>
The seg6_validate_srh() is used to validate SRH for three cases:

case1: SRH of data-plane SRv6 packets to be processed by the Linux kernel.
Case2: SRH of the netlink message received  from user-space (iproute2)
Case3: SRH injected into packets through setsockopt

In case1, the SRH can be encoded in the Reduced way (i.e., first SID is
carried in DA only and not represented as SID in the SRH) and the
seg6_validate_srh() now handles this case correctly.

In case2 and case3, the SRH shouldn’t be encoded in the Reduced way
otherwise we lose the first segment (i.e., the first hop).

The current implementation of the seg6_validate_srh() allow SRH of case2
and case3 to be encoded in the Reduced way. This leads a slab-out-of-bounds
problem.

This patch verifies SRH of case1, case2 and case3. Allowing case1 to be
reduced while preventing SRH of case2 and case3 from being reduced .

Reported-by: syzbot+e8c028b62439eac42073@syzkaller.appspotmail.com
Reported-by: YueHaibing &lt;yuehaibing@huawei.com&gt;
Fixes: 0cb7498f234e ("seg6: fix SRH processing to comply with RFC8754")
Signed-off-by: Ahmed Abdelsalam &lt;ahabdels@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
