From patchwork Tue Oct 11 00:58:57 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Liping Zhang X-Patchwork-Id: 680597 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 3stJYC3m14z9s9Y for ; Tue, 11 Oct 2016 11:59:27 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=eDOflULS; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752903AbcJKA7A (ORCPT ); Mon, 10 Oct 2016 20:59:00 -0400 Received: from mail-vk0-f51.google.com ([209.85.213.51]:32907 "EHLO mail-vk0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752679AbcJKA66 (ORCPT ); Mon, 10 Oct 2016 20:58:58 -0400 Received: by mail-vk0-f51.google.com with SMTP id z126so5712032vkd.0; Mon, 10 Oct 2016 17:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0kUpAmECiuW9B6+aEFmSvQz9GSzl4FbLewEQCbc1UkA=; b=eDOflULSpx3Aw/vKjYfp3Gb91KsJo/6TsEy/J18iFLoOpjZY0oGrPgxtersACSaZvn 1gx4EhUr20YAV8KPfHvtW7lbP9u+yo3TRIK5+rGiWjt4GTP33QJn48qS8luJMA0thdtj uhU4k0avlpDeyoLQ8EoFTJfboZgftnVjI2rtiJPgORPfJ6qbfKNJpfb6uStnaHPUFmQP gTzMx/zf+dTRtN8GCfFnigsyPMsx/lkvlJFrs3VRmhlEAcxDz2n7ZjoI0NCmnP//lqnz bLz2fwXBe4C7lGuI+0wyFXlLTLLwzf+E9eOS/S8oaPTIN+TuQu50gLeABSoXCsEv1sTC k5MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0kUpAmECiuW9B6+aEFmSvQz9GSzl4FbLewEQCbc1UkA=; b=SSbsdOX3WpQMi16L0E4vhymWOFqgN8nUPP7fIvd7G593H9dqs8Q+lafOyad/uwe/Cm KERbrjy7hvIMm98NolIDtggYI2RW8CVcQXJCm48eC0A9jaeuvjkUyuHA5Gj9bSnPcNzX dfcw3uyVkdGHhjgMznF4kmdU0a1k8PFrbGZX7RLPJyQgwQqzXuYd0vcI0flj/0EwGMP+ 90IDkKqLhQ3QM9tN6eL1RlpKfZKC0du1QnrbT0NktBu5TZ6C7xXmwweqeacI5LV57JRK E7m/Ald8qxpZ0Hih611PQ3kFqY0oXkyQ+wj1UKBRCXK0x2LTdaEp2B3kQIqbsUlb7rR5 XtyQ== X-Gm-Message-State: AA6/9Rkl7Fvo4Ez7heVG1N4EypPhVTofKiLaIN2SO9h0CI8vKKUAwtK1edjw9az8YRR86Fy+MlaovMw12mtxhw== X-Received: by 10.31.120.70 with SMTP id t67mr1078289vkc.140.1476147537409; Mon, 10 Oct 2016 17:58:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.56.21 with HTTP; Mon, 10 Oct 2016 17:58:57 -0700 (PDT) In-Reply-To: References: From: Liping Zhang Date: Tue, 11 Oct 2016 08:58:57 +0800 Message-ID: Subject: Re: kernel v4.8: iptables logs are truncated with the 4.8 kernel? To: Chris Caputo Cc: Vishwanath Pai , Pablo Neira Ayuso , Justin Piszcz , linux-kernel@vger.kernel.org, Linux Kernel Network Developers Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 2016-10-11 2:33 GMT+08:00 Chris Caputo : >> >> What numbers did you specify after --nflog-size option? >> --nflog-size 0 or ...? If you want log the whole packet to >> the ulogd, please do not specify this nflog-size option. > > Not specifying nflog-size does not appear to log the whole packet... > > If "--nflog-size" is unspecified, and the iptables config is left > unchanged when the kernel is upgraded to 4.8, ulogd-2.0.5 crashes. > > If "--nflog-size 0" is used, ulogd-2.0.5 crashes. > > If "--nflog-size" is used with size 1 or greater, ulogd-2.0.5 is fine. > >> > I'm surprised to see a kernel change cause unexpected userspace segfaults, >> > so further investigation into a kernel fix would seem a good idea. >> >> According to the original user's manual, nflog-range option was >> designed to be the number of bytes copied to userspace, but >> unfortunately there's a bug from the beginning and it never works, >> i.e. in kernel, it just ignored this option. >> >> Try to change the current nflog-range option's semantics may >> cause unexpected results(maybe like this ulogd crash) ... >> >> In order to keep compatibility, Vishwanath introduce a new >> nflog-size option and keep nflog-range unchanged. If you just >> upgrade the kernel, and do not change iptables rules, this >> problem will not happen. > > I am reporting that the problem does happen simply with an upgrade to > kernel 4.8 and no other changes. When "--nflog-size" is unspecified or > set to 0, the bug in ulogd-2.0.5 gets triggered. > > I agree there is a bug in ulogd-2.0.5 that this kernel change exposed, but > I am trying to explain that all ulogd users risk this segfault if they > upgrade to kernel 4.8 and don't either update to a fixed ulogd (possibly > using your patch below) or an unreleased iptables with iptables config > changes to implement nflog-size on each NFLOG target. Yes, thanks for clarifying this. There's a bug in kernel, can you try this patch: li.u.ulog.flags |= NF_LOG_F_COPY_LEN; Thanks diff --git a/net/netfilter/xt_NFLOG.c b/net/netfilter/xt_NFLOG.c index 018eed7..8c069b4 100644 --- a/net/netfilter/xt_NFLOG.c +++ b/net/netfilter/xt_NFLOG.c @@ -32,6 +32,7 @@ nflog_tg(struct sk_buff *skb, const struct xt_action_param *par) li.u.ulog.copy_len = info->len; li.u.ulog.group = info->group; li.u.ulog.qthreshold = info->threshold; + li.u.ulog.flags = 0; if (info->flags & XT_NFLOG_F_COPY_LEN)