stack corruption with EBT_ENTRY_ITERATE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 Hi All,

Observing a stack corruption when we are trying to install multiple ebtable rules on 32-bit arm arch (not tried on 64-bit). An out of bounds access is observed beyond the virtual memory region that was allocated for storing the entries.

 do_replace() {
newinfo->entries = __vmalloc(tmp.entries_size,GFP_KERNEL_ACCOUNT,
                                               PAGE_KERNEL);
                  if (!newinfo->entries) {
                      ret = -ENOMEM;
                      goto free_newinfo;
          }
 }

This panic is seen when the entries_size is at the boundary of PAGE_SIZE (4K).
 If the entries_size is well within limits of 4K, no issues observed.
.
 Through debug prints observed that the entries are clean, but
strangely when the control returns from EBT_ENTRY_ITERATE code the panic is observed.

Tried changing the macro into a function, assuming that variable args being passed
 could have been messing up the stack somehow. To my surprise with fixed
 argument functions issue is no longer observed.

Can you guys help share inputs to help understand the problem why the variable args is a problem and not function with fixed args.. Any known issues on 32-bit arm architecture
 similar to this?

Also, I found this change https://www.spinics.net/lists/netdev/msg144567.html which was submitted but didn't get accepted, could not get the discussion details.
 Note that this change also helps resolve the panic issue.

[ 1640.924251] Unable to handle kernel paging request at virtual address d7908008
[ 1640.924315] pgd = c2d1c000
[ 1640.938287] [d7908008] *pgd=87e8d811, *pte=00000000, *ppte=00000000
[ 1640.938357] Internal error: Oops: 7 [#1] PREEMPT ARM
[ 1640.967760] CPU: 0 PID: 8398 Comm: ebtables Tainted: G W O 4.14.206 #1
[ 1640.997394] task: c2ce21c0 task.stack: c9028000
[ 1641.005545] PC is at translate_table+0x1c8/0xe54
[ 1641.009882] LR is at 0x19
[ 1641.315119] [<c0c6e6b4>] (translate_table) from [<c0c6fc48>] (do_ebt_set_ctl+0x688/0xd2c) [ 1641.323268] [<c0c6fc48>] (do_ebt_set_ctl) from [<c0b4c1a4>] (nf_sockopt+0x124/0x134) [ 1641.331426] [<c0b4c1a4>] (nf_sockopt) from [<c0b4c068>] (nf_setsockopt+0x54/0x6c) [ 1641.339238] [<c0b4c068>] (nf_setsockopt) from [<c0b9000c>] (ip_setsockopt+0xe30/0x1304) [ 1641.346619] [<c0b9000c>] (ip_setsockopt) from [<c0bb66fc>] (raw_setsockopt+0x104/0x11c) [ 1641.354431] [<c0bb66fc>] (raw_setsockopt) from [<c0af34b0>] (sock_common_setsockopt+0x44/0x4c) [ 1641.362422] [<c0af34b0>] (sock_common_setsockopt) from [<c0aec384>] (SyS_setsockopt+0xcc/0x104) [ 1641.371100] [<c0aec384>] (SyS_setsockopt) from [<c01085a0>] (ret_fast_syscall+0x0/0x28)
[ 1641.379691] Code: 1affffa4 e5921000 e3a04000 e592902c (e592206c)
[ 1641.398618] ---[ end trace 0bce651f43449794 ]---

 Regards,
 Sharath



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux