netdev - Re: Patch to fix 'ip' utility recvmsg with ancillary data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Jul 2021 08:48:17 +0000
From:   Lahav Daniel Schlesinger <lschlesinger@...venets.com>
To:     David Ahern <dsahern@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "nicolas.dichtel@...nd.com" <nicolas.dichtel@...nd.com>
Subject: Re: Patch to fix 'ip' utility recvmsg with ancillary data

Hi David, thanks for reviewing the patch!
Here is the updated patch, I hope it's okay now:

ipmonitor: Fix recvmsg with ancillary data

A successful call to recvmsg() causes msg.msg_controllen to contain the length
of the received ancillary data. However, the current code in the 'ip' utility
doesn't reset this value after each recvmsg().

This means that if a call to recvmsg() doesn't have ancillary data, then
'msg.msg_controllen' will be set to 0, causing future recvmsg() which do
contain ancillary data to get MSG_CTRUNC set in msg.msg_flags.

This fixes 'ip monitor' running with the all-nsid option - With this option the
kernel passes the nsid as ancillary data. If while 'ip monitor' is running an
even on the current netns is received, then no ancillary data will be sent,
causing 'msg.msg_controllen' to be set to 0, which causes 'ip monitor' to
indefinitely print "[nsid current]" instead of the real nsid.

Fixes: 449b824ad196 ("ipmonitor: allows to monitor in several netns")
Cc: Nicolas Dichtel <nicolas.dichtel@...nd.com>
Signed-off-by: Lahav Schlesinger <lschlesinger@...venets.com>
---
 lib/libnetlink.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 2f2cc1fe..39a552df 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -1138,16 +1138,16 @@ int rtnl_listen(struct rtnl_handle *rtnl,
    char   buf[16384];
    char   cmsgbuf[BUFSIZ];

-   if (rtnl->flags & RTNL_HANDLE_F_LISTEN_ALL_NSID) {
-       msg.msg_control = &cmsgbuf;
-       msg.msg_controllen = sizeof(cmsgbuf);
-   }
-
    iov.iov_base = buf;
    while (1) {
        struct rtnl_ctrl_data ctrl;
        struct cmsghdr *cmsg;

+       if (rtnl->flags & RTNL_HANDLE_F_LISTEN_ALL_NSID) {
+           msg.msg_control = &cmsgbuf;
+           msg.msg_controllen = sizeof(cmsgbuf);
+       }
+
        iov.iov_len = sizeof(buf);
        status = recvmsg(rtnl->fd, &msg, 0);



> On 13 Jul 2021, at 19:30, David Ahern <dsahern@...il.com> wrote:
> 
> On 7/13/21 2:09 AM, Lahav Daniel Schlesinger wrote:
>> 
>> 
>> A successful call to recvmsg() causes msg.msg_controllen to contain the length of the received ancillary data. However, the current code in the 'ip' utility doesn't reset this value after each recvmsg().
>> 
>> This means that if a call to recvmsg() doesn't have ancillary data, then msg.msg_controllen will be set to 0, causing future recvmsg() which do contain ancillary data to get MSG_CTRUNC set in msg.msg_flags.
>> 
>> This fixes 'ip monitor' running with the all-nsid option - With this option the kernel passes the nsid as ancillary data. If while 'ip monitor' is running an even on the current netns is received, then no ancillary data will be sent, causing msg.msg_controllen to be set to 0, which causes 'ip monitor' to indefinitely print "[nsid current]" instead of the real nsid.
>> 
> 
> patch looks right. Can you send it as a formal patch with a commit log
> message, Signed-off-by, etc. See  'git log' for expected format and
> Documentation/process/submitting-patches.rst in the kernel tree. Make
> sure you add:
> 
> Fixes: 449b824ad196 (“ipmonitor: allows to monitor in several netns”)
> Cc: Nicolas Dichtel <nicolas.dichtel@...nd.com>
> 
> and make sure Nicolas is cc'ed on the send.