From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9248F41B81 for ; Mon, 30 Jan 2023 15:26:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8705940EE2; Mon, 30 Jan 2023 15:26:16 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 32BBD40C35 for ; Mon, 30 Jan 2023 15:26:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675088773; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hP6h/ykztQAoyfTPkLSdQv05IRl6j8JfqyEjuPr3v6Y=; b=KqRAeqtKN7w+/l5xJUKyFCIF06qw/S7Z1acy9vgcEFBVNVaj4Erxl9gtmn1a62W40QGs6t MJ9SkXxF7ievEBb6IAERqdol1tbFzIwgZctRIm026AvzkWMZDTGmi1Sdsk5rL4QwOM2HMI +PeDTc+/0tDOEfinRbWzll4eSnU2DWU= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-606-AkJV9soDPzyCWWIU3ywevA-1; Mon, 30 Jan 2023 09:26:10 -0500 X-MC-Unique: AkJV9soDPzyCWWIU3ywevA-1 Received: by mail-pl1-f197.google.com with SMTP id t1-20020a170902e1c100b0019668eef362so3023112pla.3 for ; Mon, 30 Jan 2023 06:26:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hP6h/ykztQAoyfTPkLSdQv05IRl6j8JfqyEjuPr3v6Y=; b=HxhWRSUO7MIXaXGrIQLwM9cD7aHjBGubhWHMBKgXockzA24AMvpuFFgprDGUxizOJO Fb/H2f6VFSFSovo+eij89wOpMtQv9bb67cMYqfUO9CDj6zLLt4NimmsdkIpinCRBpopZ Ci+iHQFqbKl4hLQqY0e2URl26EIHH3TQEAFJE6lescwdO3XIuI4XTjXaTr82uLx4Sdfu MHf1qqxsCWyZTQw3E1I9bHhEdt+P2yUhcJtmXuvMzwu2JN0Y+AvODn5RhZIgQnEKaJex 5xeuhSJXCB2eMqhhKiqVB15X3Ohe/cpftAs4EYbPDIkMaitBpFjimLWIObGvVah5oPa8 f+iQ== X-Gm-Message-State: AFqh2koyg0cKb80ClLxeOnMs99U1jCASaoaZ0rYdM91DteepEL24bQ/x 69Ds899pldT6Ictt3a22maNW4MAR9rZIJPJO4M672gi2cYYrJzqK9gl8+C0fVmF5o6mg8loUWRp Pon8qkrqrNg34GM0T6rV1bdA= X-Received: by 2002:a63:c052:0:b0:477:27f7:794a with SMTP id z18-20020a63c052000000b0047727f7794amr5218069pgi.58.1675088769318; Mon, 30 Jan 2023 06:26:09 -0800 (PST) X-Google-Smtp-Source: AMrXdXs/TdCBRHVfPOAf6RLieNGUufFvSHcjpOOeSVRJ9I2HZSiNmEviN7ymFwSSKP4RJU3kTQBg8d1MV6De7ZEY8vw= X-Received: by 2002:a63:c052:0:b0:477:27f7:794a with SMTP id z18-20020a63c052000000b0047727f7794amr5218058pgi.58.1675088769013; Mon, 30 Jan 2023 06:26:09 -0800 (PST) MIME-Version: 1.0 References: <20230127165540.37863-1-maxime.coquelin@redhat.com> <20230127165540.37863-2-maxime.coquelin@redhat.com> In-Reply-To: From: David Marchand Date: Mon, 30 Jan 2023 15:25:57 +0100 Message-ID: Subject: Re: [PATCH v2 1/2] vhost: fix possible FDs leak To: Maxime Coquelin Cc: dev@dpdk.org, chenbo.xia@intel.com, stable@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Mon, Jan 30, 2023 at 10:46 AM Maxime Coquelin wrote: > > > > On 1/29/23 10:25, David Marchand wrote: > > On Fri, Jan 27, 2023 at 5:55 PM Maxime Coquelin > > wrote: > >> > >> On failure, read_vhost_message() only closed the message > >> FDs if the header size was unexpected, but there are other > >> cases where it is required. For exemple in the case the > >> payload size read from the header is greater than the > >> expected maximum payload size. > >> > >> This patch fixes this by closing all messages FDs in all > >> error cases. > >> > >> Fixes: bf472259dde6 ("vhost: fix possible denial of service by leaking FDs") > >> Cc: stable@dpdk.org > >> > >> Signed-off-by: Maxime Coquelin > > > > Reviewed-by: David Marchand > > > > We mentionned offlist that the request type can be logged to help with debug. > > Do you intend to add this as a follow up patch? > > > > > > Thinking about it, that's not that trivial because read_vhost_message() > is called for both master and slave channels, so we would need to > differentiate between both to print proper request name. > > It is doable by comparing the file descriptor passed as parameter with > the slave one stored in struct virtio_net, but that's not super clean. >From the 3 different callers of read_vhost_message, I think the only one that could gain from this debug is vhost_user_msg_handler(). And here, we could look at the message content on read_vhost_message return. Like this untested and ugly snippet: diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c index 943058725e..1556f21a58 100644 --- a/lib/vhost/vhost_user.c +++ b/lib/vhost/vhost_user.c @@ -2994,13 +2994,10 @@ vhost_user_msg_handler(int vid, int fd) } } + ctx.msg.request.master = VHOST_USER_NONE; ret = read_vhost_message(dev, fd, &ctx); - if (ret <= 0) { - if (ret < 0) - VHOST_LOG_CONFIG(dev->ifname, ERR, "vhost read message failed\n"); - else - VHOST_LOG_CONFIG(dev->ifname, INFO, "vhost peer closed\n"); - + if (ret == 0) { + VHOST_LOG_CONFIG(dev->ifname, INFO, "vhost peer closed\n"); return -1; } @@ -3010,6 +3007,14 @@ vhost_user_msg_handler(int vid, int fd) else msg_handler = NULL; + if (ret < 0) { + VHOST_LOG_CONFIG(dev->ifname, ERR, "vhost read message %s%s%sfailed\n", + msg_handler != NULL ? "for " : "", + msg_handler != NULL ? msg_handler->description : "", + msg_handler != NULL ? " " : ""); + return -1; + } + if (msg_handler != NULL && msg_handler->description != NULL) { if (request != VHOST_USER_IOTLB_MSG) VHOST_LOG_CONFIG(dev->ifname, INFO, -- David Marchand