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]
Message-ID: <D2E7CEEB-B195-4A02-8D09-6595D74A5812@drivenets.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ