From: Patrick McHardy <kaber@trash.net>
To: "Christoph A." <casmls@gmail.com>
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
Subject: Re: nftables: NULL pointer dereference
Date: Thu, 23 Jul 2009 17:03:44 +0200 [thread overview]
Message-ID: <4A687BD0.1030906@trash.net> (raw)
In-Reply-To: <4A6856E6.9030600@trash.net>
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
Patrick McHardy wrote:
> Christoph A. wrote:
>> when executing the testscript [1] (just to see if my nftables setup is
>> working), I get the following stack trace.
>>
>> [1] http://article.gmane.org/gmane.linux.network/122512
>>
>> I'm using the latest version from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nft-2.6.git
>> kernel config is attached
>>
>> BUG: unable to handle kernel NULL pointer dereference at 00000014
>> IP: [<f8b471ff>] nft_validate_data_load+0x20/0x53 [nf_tables]
>
> Thanks for the report. This is likely happening because the kernel
> includes support for some changes for which I haven't pushed out the
> corresponding userspace support yet, but it certainly shouldn't oops.
> I'll look into it ...
I've added and pushed out this patch to fix it, thanks.
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 2754 bytes --]
commit 25e43454caa8cb21c9a8ebea2259a43cace18829
Author: Patrick McHardy <kaber@trash.net>
Date: Thu Jul 23 17:12:29 2009 +0200
netfilter: nf_tables: fix oops in nft_validate_data_load()
As reported by Christoph A. <casmls@gmail.com>, nftables will
oops in nft_validate_data_load() when running the script from
http://article.gmane.org/gmane.linux.network/122512
BUG: unable to handle kernel NULL pointer dereference at 00000014
IP: [<f8b471ff>] nft_validate_data_load+0x20/0x53 [nf_tables]
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/class/net/lo/operstate
Modules linked in: nft_log nft_counter nf_tables_ipv4 nf_tables ipv6 loop parport_pc parport psmouse battery ac serio_raw button i2c_piix4 pcspkr i2c_core evdev ext3 jbd mbcache ide_cd_mod cdrom ide_gd_mod ata_generic ata_piix libata scsi_mod ide_pci_generic floppy piix pcnet32 mii ide_core thermal fan thermal_sys
Pid: 1916, comm: test-script Not tainted (2.6.30-rc1nft3 #1) VirtualBox
EIP: 0060:[<f8b471ff>] EFLAGS: 00010246 CPU: 0
EIP is at nft_validate_data_load+0x20/0x53 [nf_tables]
EAX: f7016a00 EBX: 00000000 ECX: 00030000 EDX: 00000000
ESI: f79c3b10 EDI: f6867e84 EBP: f79c3c74 ESP: f79c3ae4
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
Process test-script (pid: 1916, ti=f79c2000 task=f790fb40 task.ti=f79c2000)
Stack:
00000000 f8b4a134 ffffff00 ffffff00 00000004 f79c3b10 f8b4d118 00000002
f79c3b44 f8b494bf f790fcfc 00000000 f6ebcc78 f6ebcc80 00000000 00000000
0000001c f6867e80 f79c3b94 f79c3c74 f79c3b28 00000000 f6867e40 00000002
Call Trace:
[<f8b4a134>] ? nft_immediate_init+0x5d/0x85 [nf_tables]
[<f8b494bf>] ? nf_tables_newexpr+0x7e/0xa8 [nf_tables]
[<f8b4985c>] ? nf_tables_newrule+0x373/0x447 [nf_tables]
The reason is that nft_validate_data_load() unconditionally dereferences
data->chain, while this is only valid for GOTO/JUMP verdicts.
Fix by adding a check for the appropriate verdicts.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 64e5294..4d19a51 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -2297,7 +2297,8 @@ int nft_validate_data_load(const struct nft_ctx *ctx, enum nft_registers reg,
if (data == NULL || type != NFT_DATA_VERDICT)
return -EINVAL;
- if (ctx->chain->level + 1 > data->chain->level) {
+ if ((data->verdict == NFT_GOTO || data->verdict == NFT_JUMP) &&
+ ctx->chain->level + 1 > data->chain->level) {
if (ctx->chain->level + 1 == NFT_JUMP_STACK_SIZE)
return -EMLINK;
data->chain->level = ctx->chain->level + 1;
next prev parent reply other threads:[~2009-07-23 15:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-23 12:26 nftables: NULL pointer dereference Patrick McHardy
2009-07-23 15:03 ` Patrick McHardy [this message]
2009-07-23 23:48 ` Christoph A.
-- strict thread matches above, loose matches on Subject: below --
2009-07-19 22:12 Christoph A.
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=4A687BD0.1030906@trash.net \
--to=kaber@trash.net \
--cc=casmls@gmail.com \
--cc=netfilter-devel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).