From: kernel test robot <lkp@intel.com>
To: Andrii Melnychenko <a.melnychenko@vyos.io>,
pablo@netfilter.org, kadlec@netfilter.org, fw@strlen.de,
phil@nwl.cc
Cc: oe-kbuild-all@lists.linux.dev, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] netfilter: Added nfct_seqadj_ext_add() for ftp's conntrack.
Date: Wed, 15 Oct 2025 12:15:47 +0800 [thread overview]
Message-ID: <202510151220.i78zzYsl-lkp@intel.com> (raw)
In-Reply-To: <20251014114334.4167561-1-a.melnychenko@vyos.io>
Hi Andrii,
kernel test robot noticed the following build errors:
[auto build test ERROR on netfilter-nf/main]
[also build test ERROR on nf-next/master horms-ipvs/master linus/master v6.18-rc1 next-20251014]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Andrii-Melnychenko/netfilter-Added-nfct_seqadj_ext_add-for-ftp-s-conntrack/20251014-194524
base: https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git main
patch link: https://lore.kernel.org/r/20251014114334.4167561-1-a.melnychenko%40vyos.io
patch subject: [PATCH 1/1] netfilter: Added nfct_seqadj_ext_add() for ftp's conntrack.
config: m68k-multi_defconfig (https://download.01.org/0day-ci/archive/20251015/202510151220.i78zzYsl-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251015/202510151220.i78zzYsl-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510151220.i78zzYsl-lkp@intel.com/
All errors (new ones prefixed by >>):
net/netfilter/nf_conntrack_ftp.c: In function 'help':
>> net/netfilter/nf_conntrack_ftp.c:394:25: error: implicit declaration of function 'nfct_seqadj_ext_add'; did you mean 'nf_ct_helper_ext_add'? [-Wimplicit-function-declaration]
394 | nfct_seqadj_ext_add(ct);
| ^~~~~~~~~~~~~~~~~~~
| nf_ct_helper_ext_add
vim +394 net/netfilter/nf_conntrack_ftp.c
368
369 static int help(struct sk_buff *skb,
370 unsigned int protoff,
371 struct nf_conn *ct,
372 enum ip_conntrack_info ctinfo)
373 {
374 unsigned int dataoff, datalen;
375 const struct tcphdr *th;
376 struct tcphdr _tcph;
377 const char *fb_ptr;
378 int ret;
379 u32 seq;
380 int dir = CTINFO2DIR(ctinfo);
381 unsigned int matchlen, matchoff;
382 struct nf_ct_ftp_master *ct_ftp_info = nfct_help_data(ct);
383 struct nf_conntrack_expect *exp;
384 union nf_inet_addr *daddr;
385 struct nf_conntrack_man cmd = {};
386 unsigned int i;
387 int found = 0, ends_in_nl;
388 typeof(nf_nat_ftp_hook) nf_nat_ftp;
389
390 /* Until there's been traffic both ways, don't look in packets. */
391 if (ctinfo != IP_CT_ESTABLISHED &&
392 ctinfo != IP_CT_ESTABLISHED_REPLY) {
393 if (!nf_ct_is_confirmed(ct))
> 394 nfct_seqadj_ext_add(ct);
395 pr_debug("ftp: Conntrackinfo = %u\n", ctinfo);
396 return NF_ACCEPT;
397 }
398
399 if (unlikely(skb_linearize(skb)))
400 return NF_DROP;
401
402 th = skb_header_pointer(skb, protoff, sizeof(_tcph), &_tcph);
403 if (th == NULL)
404 return NF_ACCEPT;
405
406 dataoff = protoff + th->doff * 4;
407 /* No data? */
408 if (dataoff >= skb->len) {
409 pr_debug("ftp: dataoff(%u) >= skblen(%u)\n", dataoff,
410 skb->len);
411 return NF_ACCEPT;
412 }
413 datalen = skb->len - dataoff;
414
415 /* seqadj (nat) uses ct->lock internally, nf_nat_ftp would cause deadlock */
416 spin_lock_bh(&nf_ftp_lock);
417 fb_ptr = skb->data + dataoff;
418
419 ends_in_nl = (fb_ptr[datalen - 1] == '\n');
420 seq = ntohl(th->seq) + datalen;
421
422 /* Look up to see if we're just after a \n. */
423 if (!find_nl_seq(ntohl(th->seq), ct_ftp_info, dir)) {
424 /* We're picking up this, clear flags and let it continue */
425 if (unlikely(ct_ftp_info->flags[dir] & NF_CT_FTP_SEQ_PICKUP)) {
426 ct_ftp_info->flags[dir] ^= NF_CT_FTP_SEQ_PICKUP;
427 goto skip_nl_seq;
428 }
429
430 /* Now if this ends in \n, update ftp info. */
431 pr_debug("nf_conntrack_ftp: wrong seq pos %s(%u) or %s(%u)\n",
432 ct_ftp_info->seq_aft_nl_num[dir] > 0 ? "" : "(UNSET)",
433 ct_ftp_info->seq_aft_nl[dir][0],
434 ct_ftp_info->seq_aft_nl_num[dir] > 1 ? "" : "(UNSET)",
435 ct_ftp_info->seq_aft_nl[dir][1]);
436 ret = NF_ACCEPT;
437 goto out_update_nl;
438 }
439
440 skip_nl_seq:
441 /* Initialize IP/IPv6 addr to expected address (it's not mentioned
442 in EPSV responses) */
443 cmd.l3num = nf_ct_l3num(ct);
444 memcpy(cmd.u3.all, &ct->tuplehash[dir].tuple.src.u3.all,
445 sizeof(cmd.u3.all));
446
447 for (i = 0; i < ARRAY_SIZE(search[dir]); i++) {
448 found = find_pattern(fb_ptr, datalen,
449 search[dir][i].pattern,
450 search[dir][i].plen,
451 search[dir][i].skip,
452 search[dir][i].term,
453 &matchoff, &matchlen,
454 &cmd,
455 search[dir][i].getnum);
456 if (found) break;
457 }
458 if (found == -1) {
459 /* We don't usually drop packets. After all, this is
460 connection tracking, not packet filtering.
461 However, it is necessary for accurate tracking in
462 this case. */
463 nf_ct_helper_log(skb, ct, "partial matching of `%s'",
464 search[dir][i].pattern);
465 ret = NF_DROP;
466 goto out;
467 } else if (found == 0) { /* No match */
468 ret = NF_ACCEPT;
469 goto out_update_nl;
470 }
471
472 pr_debug("conntrack_ftp: match `%.*s' (%u bytes at %u)\n",
473 matchlen, fb_ptr + matchoff,
474 matchlen, ntohl(th->seq) + matchoff);
475
476 exp = nf_ct_expect_alloc(ct);
477 if (exp == NULL) {
478 nf_ct_helper_log(skb, ct, "cannot alloc expectation");
479 ret = NF_DROP;
480 goto out;
481 }
482
483 /* We refer to the reverse direction ("!dir") tuples here,
484 * because we're expecting something in the other direction.
485 * Doesn't matter unless NAT is happening. */
486 daddr = &ct->tuplehash[!dir].tuple.dst.u3;
487
488 /* Update the ftp info */
489 if ((cmd.l3num == nf_ct_l3num(ct)) &&
490 memcmp(&cmd.u3.all, &ct->tuplehash[dir].tuple.src.u3.all,
491 sizeof(cmd.u3.all))) {
492 /* Enrico Scholz's passive FTP to partially RNAT'd ftp
493 server: it really wants us to connect to a
494 different IP address. Simply don't record it for
495 NAT. */
496 if (cmd.l3num == PF_INET) {
497 pr_debug("NOT RECORDING: %pI4 != %pI4\n",
498 &cmd.u3.ip,
499 &ct->tuplehash[dir].tuple.src.u3.ip);
500 } else {
501 pr_debug("NOT RECORDING: %pI6 != %pI6\n",
502 cmd.u3.ip6,
503 ct->tuplehash[dir].tuple.src.u3.ip6);
504 }
505
506 /* Thanks to Cristiano Lincoln Mattos
507 <lincoln@cesar.org.br> for reporting this potential
508 problem (DMZ machines opening holes to internal
509 networks, or the packet filter itself). */
510 if (!loose) {
511 ret = NF_ACCEPT;
512 goto out_put_expect;
513 }
514 daddr = &cmd.u3;
515 }
516
517 nf_ct_expect_init(exp, NF_CT_EXPECT_CLASS_DEFAULT, cmd.l3num,
518 &ct->tuplehash[!dir].tuple.src.u3, daddr,
519 IPPROTO_TCP, NULL, &cmd.u.tcp.port);
520
521 /* Now, NAT might want to mangle the packet, and register the
522 * (possibly changed) expectation itself. */
523 nf_nat_ftp = rcu_dereference(nf_nat_ftp_hook);
524 if (nf_nat_ftp && ct->status & IPS_NAT_MASK)
525 ret = nf_nat_ftp(skb, ctinfo, search[dir][i].ftptype,
526 protoff, matchoff, matchlen, exp);
527 else {
528 /* Can't expect this? Best to drop packet now. */
529 if (nf_ct_expect_related(exp, 0) != 0) {
530 nf_ct_helper_log(skb, ct, "cannot add expectation");
531 ret = NF_DROP;
532 } else
533 ret = NF_ACCEPT;
534 }
535
536 out_put_expect:
537 nf_ct_expect_put(exp);
538
539 out_update_nl:
540 /* Now if this ends in \n, update ftp info. Seq may have been
541 * adjusted by NAT code. */
542 if (ends_in_nl)
543 update_nl_seq(ct, seq, ct_ftp_info, dir, skb);
544 out:
545 spin_unlock_bh(&nf_ftp_lock);
546 return ret;
547 }
548
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
prev parent reply other threads:[~2025-10-15 4:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 11:43 [PATCH 1/1] netfilter: Added nfct_seqadj_ext_add() for ftp's conntrack Andrii Melnychenko
2025-10-14 12:25 ` Florian Westphal
2025-10-15 4:15 ` kernel test robot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202510151220.i78zzYsl-lkp@intel.com \
--to=lkp@intel.com \
--cc=a.melnychenko@vyos.io \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.