From patchwork Mon Apr 30 22:37:07 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Gortmaker X-Patchwork-Id: 155964 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 44233B6F9D for ; Tue, 1 May 2012 08:37:32 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757380Ab2D3Wha (ORCPT ); Mon, 30 Apr 2012 18:37:30 -0400 Received: from mail1.windriver.com ([147.11.146.13]:45991 "EHLO mail1.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757367Ab2D3WhX (ORCPT ); Mon, 30 Apr 2012 18:37:23 -0400 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca [147.11.189.40]) by mail1.windriver.com (8.14.3/8.14.3) with ESMTP id q3UMbK8v006334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Apr 2012 15:37:20 -0700 (PDT) Received: from yow-pgortmak-d2.corp.ad.wrs.com (128.224.146.165) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.1.255.0; Mon, 30 Apr 2012 15:37:20 -0700 From: Paul Gortmaker To: CC: , , , , Subject: [PATCH net-next 09/10] tipc: Reject payload messages with invalid message type Date: Mon, 30 Apr 2012 18:37:07 -0400 Message-ID: <1335825428-16053-10-git-send-email-paul.gortmaker@windriver.com> X-Mailer: git-send-email 1.7.9.6 In-Reply-To: <1335825428-16053-1-git-send-email-paul.gortmaker@windriver.com> References: <1335825428-16053-1-git-send-email-paul.gortmaker@windriver.com> MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Allan Stephens Adds check to ensure TIPC sockets reject incoming payload messages that have an unrecognized message type. Remove the old open question about whether TIPC_ERR_NO_PORT is the proper return value. It is appropriate here since there are valid instances where another node can make use of the reply, and at this point in time the host is already broadcasting TIPC data, so there are no real security concerns. Signed-off-by: Allan Stephens Signed-off-by: Paul Gortmaker --- net/tipc/socket.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/net/tipc/socket.c b/net/tipc/socket.c index 6d4991e..3c00b40 100644 --- a/net/tipc/socket.c +++ b/net/tipc/socket.c @@ -1223,11 +1223,8 @@ static u32 filter_rcv(struct sock *sk, struct sk_buff *buf) /* Reject message if it is wrong sort of message for socket */ - /* - * WOULD IT BE BETTER TO JUST DISCARD THESE MESSAGES INSTEAD? - * "NO PORT" ISN'T REALLY THE RIGHT ERROR CODE, AND THERE MAY - * BE SECURITY IMPLICATIONS INHERENT IN REJECTING INVALID TRAFFIC - */ + if (msg_type(msg) > TIPC_DIRECT_MSG) + return TIPC_ERR_NO_PORT; if (sock->state == SS_READY) { if (msg_connected(msg))