netdev - Re: off by one in update_nl

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] [day] [month] [year] [list]

Date:	Tue, 05 Jan 2010 08:43:24 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Dan Carpenter <error27@...il.com>
CC:	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: off by one in update_nl_seq()

Dan Carpenter wrote:
> net/netfilter/nf_conntrack_ftp.c
>    321  /* We don't update if it's older than what we have. */
>    322  static void update_nl_seq(struct nf_conn *ct, u32 nl_seq,
>    323                            struct nf_ct_ftp_master *info, int dir,
>    324                            struct sk_buff *skb)
>    325  {
>    326          unsigned int i, oldest = NUM_SEQ_TO_REMEMBER;
> 
> Should this be oldest = NUM_SEQ_TO_REMEMBER - 1;?  The array is 
> defined as:
> u_int32_t seq_aft_nl[IP_CT_DIR_MAX][NUM_SEQ_TO_REMEMBER];

That would break the logic further down below.

>    327
>    328          /* Look for oldest: if we find exact match, we're done. */
>    329          for (i = 0; i < info->seq_aft_nl_num[dir]; i++) {
>    330                  if (info->seq_aft_nl[dir][i] == nl_seq)
>    331                          return;
>    332
>    333                  if (oldest == info->seq_aft_nl_num[dir] ||
>    334                      before(info->seq_aft_nl[dir][i],
>    335                             info->seq_aft_nl[dir][oldest]))  
> 
> Line 335 has the possible array out of bounds I am concerned about. 

Good catch, this is definitely a bug. The entire function seems
overly complicated to select one of two possible positions. I'll
commit the attached patch to fix this after some testing.


View attachment "x" of type "text/plain" (1236 bytes)