* KASAN: vmalloc-out-of-bounds in ipt_do_table
@ 2023-10-23 10:01 Kaustubh Pandey
2023-10-23 10:12 ` Pablo Neira Ayuso
2023-10-23 11:20 ` Florian Westphal
0 siblings, 2 replies; 5+ messages in thread
From: Kaustubh Pandey @ 2023-10-23 10:01 UTC (permalink / raw)
To: mark.tomlinson, pablo, netdev; +Cc: quic_sharathv, quic_subashab
Hi Everyone,
We have observed below issue on v5.15 kernel
[83180.055298]
==================================================================
[83180.055376] BUG: KASAN: vmalloc-out-of-bounds in ipt_do_table+0x43c/0xaf4
[83180.055464] Read of size 8 at addr ffffffc02c0f9000 by task Disposer/1686
[83180.055544] CPU: 1 PID: 1686 Comm: Disposer Tainted: G S W OE
5.15.78-android13-8-g3d973ad4cc47 #1
[83180.055613] Hardware name: Qualcomm Technologies, Inc. Kalama
MTP,davinci DVT (DT)
[83180.055655] Call trace:
[83180.055677] dump_backtrace+0x0/0x3b0
[83180.055740] show_stack+0x2c/0x3c
[83180.055792] dump_stack_lvl+0x8c/0xa8
[83180.055866] print_address_description+0x74/0x384
[83180.055940] kasan_report+0x180/0x260
[83180.056002] __asan_load8+0xb4/0xb8
[83180.056064] ipt_do_table+0x43c/0xaf4
[83180.056120] iptable_mangle_hook+0xf4/0x22c
[83180.056182] nf_hook_slow+0x90/0x198
[83180.056245] ip_mc_output+0x50c/0x67c
[83180.056302] ip_send_skb+0x88/0x1bc
[83180.056355] udp_send_skb+0x524/0x930
[83180.056415] udp_sendmsg+0x126c/0x13ac
[83180.056474] udpv6_sendmsg+0x6d4/0x1764
[83180.056539] inet6_sendmsg+0x78/0x98
[83180.056605] __sys_sendto+0x360/0x450
[83180.056667] __arm64_sys_sendto+0x80/0x9c
[83180.056725] invoke_syscall+0x80/0x218
[83180.056791] el0_svc_common+0x18c/0x1bc
[83180.056857] do_el0_svc+0x44/0xfc
[83180.056918] el0_svc+0x20/0x50
[83180.056966] el0t_64_sync_handler+0x84/0xe4
[83180.057020] el0t_64_sync+0x1a4/0x1a8
[83180.057110] Memory state around the buggy address:
[83180.057150] ffffffc02c0f8f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f8 f8 f8
[83180.057193] ffffffc02c0f8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f8 f8 f8
[83180.057237] >ffffffc02c0f9000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f8 f8 f8
[83180.057269] ^
[83180.057304] ffffffc02c0f9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f8 f8 f8
[83180.057345] ffffffc02c0f9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f8 f8 f8
[83180.057378]
==================================================================
There are no reproduction steps available for this.
I have checked along the lines and see that
https://github.com/torvalds/linux/commit/175e476b8cdf2a4de7432583b49c871345e4f8a1
is still present in this kernel.
Checked around similar lines in latest kernel and still see that
implementation hasnt changed much.
Can you pls help check if this is a known issue and was fixed in latest
or help in pointing out how to debug this further ?
Thanks,
Kaustubh
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: KASAN: vmalloc-out-of-bounds in ipt_do_table
2023-10-23 10:01 KASAN: vmalloc-out-of-bounds in ipt_do_table Kaustubh Pandey
@ 2023-10-23 10:12 ` Pablo Neira Ayuso
2023-10-25 17:22 ` Kaustubh Pandey
2023-10-23 11:20 ` Florian Westphal
1 sibling, 1 reply; 5+ messages in thread
From: Pablo Neira Ayuso @ 2023-10-23 10:12 UTC (permalink / raw)
To: Kaustubh Pandey
Cc: mark.tomlinson, netdev, quic_sharathv, quic_subashab,
netfilter-devel
Cc'ing netfilter-devel.
On Mon, Oct 23, 2023 at 03:31:25PM +0530, Kaustubh Pandey wrote:
> Hi Everyone,
>
> We have observed below issue on v5.15 kernel
>
> [83180.055298]
> ==================================================================
> [83180.055376] BUG: KASAN: vmalloc-out-of-bounds in ipt_do_table+0x43c/0xaf4
> [83180.055464] Read of size 8 at addr ffffffc02c0f9000 by task Disposer/1686
> [83180.055544] CPU: 1 PID: 1686 Comm: Disposer Tainted: G S W OE
> 5.15.78-android13-8-g3d973ad4cc47 #1
This is slightly behind current -stable. Perhaps this is missing?
commit e58a171d35e32e6e8c37cfe0e8a94406732a331f
Author: Florian Westphal <fw@strlen.de>
Date: Fri Feb 17 23:20:06 2023 +0100
netfilter: ebtables: fix table blob use-after-free
> [83180.055613] Hardware name: Qualcomm Technologies, Inc. Kalama
> MTP,davinci DVT (DT)
> [83180.055655] Call trace:
> [83180.055677] dump_backtrace+0x0/0x3b0
> [83180.055740] show_stack+0x2c/0x3c
> [83180.055792] dump_stack_lvl+0x8c/0xa8
> [83180.055866] print_address_description+0x74/0x384
> [83180.055940] kasan_report+0x180/0x260
> [83180.056002] __asan_load8+0xb4/0xb8
> [83180.056064] ipt_do_table+0x43c/0xaf4
> [83180.056120] iptable_mangle_hook+0xf4/0x22c
> [83180.056182] nf_hook_slow+0x90/0x198
> [83180.056245] ip_mc_output+0x50c/0x67c
> [83180.056302] ip_send_skb+0x88/0x1bc
> [83180.056355] udp_send_skb+0x524/0x930
> [83180.056415] udp_sendmsg+0x126c/0x13ac
> [83180.056474] udpv6_sendmsg+0x6d4/0x1764
> [83180.056539] inet6_sendmsg+0x78/0x98
> [83180.056605] __sys_sendto+0x360/0x450
> [83180.056667] __arm64_sys_sendto+0x80/0x9c
> [83180.056725] invoke_syscall+0x80/0x218
> [83180.056791] el0_svc_common+0x18c/0x1bc
> [83180.056857] do_el0_svc+0x44/0xfc
> [83180.056918] el0_svc+0x20/0x50
> [83180.056966] el0t_64_sync_handler+0x84/0xe4
> [83180.057020] el0t_64_sync+0x1a4/0x1a8
> [83180.057110] Memory state around the buggy address:
> [83180.057150] ffffffc02c0f8f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8 f8
> [83180.057193] ffffffc02c0f8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8 f8
> [83180.057237] >ffffffc02c0f9000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8 f8
> [83180.057269] ^
> [83180.057304] ffffffc02c0f9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8 f8
> [83180.057345] ffffffc02c0f9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f8 f8 f8
> [83180.057378]
> ==================================================================
>
> There are no reproduction steps available for this.
>
> I have checked along the lines and see that
> https://github.com/torvalds/linux/commit/175e476b8cdf2a4de7432583b49c871345e4f8a1
> is still present in this kernel.
> Checked around similar lines in latest kernel and still see that
> implementation hasnt changed much.
>
> Can you pls help check if this is a known issue and was fixed in latest
> or help in pointing out how to debug this further ?
>
> Thanks,
> Kaustubh
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: KASAN: vmalloc-out-of-bounds in ipt_do_table
2023-10-23 10:01 KASAN: vmalloc-out-of-bounds in ipt_do_table Kaustubh Pandey
2023-10-23 10:12 ` Pablo Neira Ayuso
@ 2023-10-23 11:20 ` Florian Westphal
2023-10-25 17:25 ` Kaustubh Pandey
1 sibling, 1 reply; 5+ messages in thread
From: Florian Westphal @ 2023-10-23 11:20 UTC (permalink / raw)
To: Kaustubh Pandey
Cc: mark.tomlinson, pablo, netdev, quic_sharathv, quic_subashab
Kaustubh Pandey <quic_kapandey@quicinc.com> wrote:
> Hi Everyone,
>
> We have observed below issue on v5.15 kernel
>
> [83180.055298]
> ==================================================================
> [83180.055376] BUG: KASAN: vmalloc-out-of-bounds in ipt_do_table+0x43c/0xaf4
Whats this? See scripts/faddr2line
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: KASAN: vmalloc-out-of-bounds in ipt_do_table
2023-10-23 10:12 ` Pablo Neira Ayuso
@ 2023-10-25 17:22 ` Kaustubh Pandey
0 siblings, 0 replies; 5+ messages in thread
From: Kaustubh Pandey @ 2023-10-25 17:22 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: mark.tomlinson, netdev, quic_sharathv, quic_subashab,
netfilter-devel
On 10/23/2023 3:42 PM, Pablo Neira Ayuso wrote:
> Cc'ing netfilter-devel.
>
> On Mon, Oct 23, 2023 at 03:31:25PM +0530, Kaustubh Pandey wrote:
>> Hi Everyone,
>>
>> We have observed below issue on v5.15 kernel
>>
>> [83180.055298]
>> ==================================================================
>> [83180.055376] BUG: KASAN: vmalloc-out-of-bounds in ipt_do_table+0x43c/0xaf4
>> [83180.055464] Read of size 8 at addr ffffffc02c0f9000 by task Disposer/1686
>> [83180.055544] CPU: 1 PID: 1686 Comm: Disposer Tainted: G S W OE
>> 5.15.78-android13-8-g3d973ad4cc47 #1
>
> This is slightly behind current -stable. Perhaps this is missing?
>
> commit e58a171d35e32e6e8c37cfe0e8a94406732a331f
> Author: Florian Westphal <fw@strlen.de>
> Date: Fri Feb 17 23:20:06 2023 +0100
>
> netfilter: ebtables: fix table blob use-after-free
>
>> [83180.055613] Hardware name: Qualcomm Technologies, Inc. Kalama
>> MTP,davinci DVT (DT)
>> [83180.055655] Call trace:
>> [83180.055677] dump_backtrace+0x0/0x3b0
>> [83180.055740] show_stack+0x2c/0x3c
>> [83180.055792] dump_stack_lvl+0x8c/0xa8
>> [83180.055866] print_address_description+0x74/0x384
>> [83180.055940] kasan_report+0x180/0x260
>> [83180.056002] __asan_load8+0xb4/0xb8
>> [83180.056064] ipt_do_table+0x43c/0xaf4
>> [83180.056120] iptable_mangle_hook+0xf4/0x22c
>> [83180.056182] nf_hook_slow+0x90/0x198
>> [83180.056245] ip_mc_output+0x50c/0x67c
>> [83180.056302] ip_send_skb+0x88/0x1bc
>> [83180.056355] udp_send_skb+0x524/0x930
>> [83180.056415] udp_sendmsg+0x126c/0x13ac
>> [83180.056474] udpv6_sendmsg+0x6d4/0x1764
>> [83180.056539] inet6_sendmsg+0x78/0x98
>> [83180.056605] __sys_sendto+0x360/0x450
>> [83180.056667] __arm64_sys_sendto+0x80/0x9c
>> [83180.056725] invoke_syscall+0x80/0x218
>> [83180.056791] el0_svc_common+0x18c/0x1bc
>> [83180.056857] do_el0_svc+0x44/0xfc
>> [83180.056918] el0_svc+0x20/0x50
>> [83180.056966] el0t_64_sync_handler+0x84/0xe4
>> [83180.057020] el0t_64_sync+0x1a4/0x1a8
>> [83180.057110] Memory state around the buggy address:
>> [83180.057150] ffffffc02c0f8f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>> f8 f8 f8
>> [83180.057193] ffffffc02c0f8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>> f8 f8 f8
>> [83180.057237] >ffffffc02c0f9000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>> f8 f8 f8
>> [83180.057269] ^
>> [83180.057304] ffffffc02c0f9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>> f8 f8 f8
>> [83180.057345] ffffffc02c0f9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>> f8 f8 f8
>> [83180.057378]
>> ==================================================================
>>
>> There are no reproduction steps available for this.
>>
>> I have checked along the lines and see that
>> https://github.com/torvalds/linux/commit/175e476b8cdf2a4de7432583b49c871345e4f8a1
>> is still present in this kernel.
>> Checked around similar lines in latest kernel and still see that
>> implementation hasnt changed much.
>>
>> Can you pls help check if this is a known issue and was fixed in latest
>> or help in pointing out how to debug this further ?
>>
>> Thanks,
>> Kaustubh
>>
Thanks Pablo, I will try after picking the shared change.
I will revert back with results.
Thanks,
Kaustubh
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: KASAN: vmalloc-out-of-bounds in ipt_do_table
2023-10-23 11:20 ` Florian Westphal
@ 2023-10-25 17:25 ` Kaustubh Pandey
0 siblings, 0 replies; 5+ messages in thread
From: Kaustubh Pandey @ 2023-10-25 17:25 UTC (permalink / raw)
To: Florian Westphal
Cc: mark.tomlinson, pablo, netdev, quic_sharathv, quic_subashab
On 10/23/2023 4:50 PM, Florian Westphal wrote:
> Kaustubh Pandey <quic_kapandey@quicinc.com> wrote:
>> Hi Everyone,
>>
>> We have observed below issue on v5.15 kernel
>>
>> [83180.055298]
>> ==================================================================
>> [83180.055376] BUG: KASAN: vmalloc-out-of-bounds in ipt_do_table+0x43c/0xaf4
>
> Whats this? See scripts/faddr2line
Unfortunately, I am unable to run faddr2line as this is on one of our customer builds.
I will have the fix tried out which was shared by Pablo and revert back with results.
Thanks,
Kaustubh
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-10-25 17:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-10-23 10:01 KASAN: vmalloc-out-of-bounds in ipt_do_table Kaustubh Pandey
2023-10-23 10:12 ` Pablo Neira Ayuso
2023-10-25 17:22 ` Kaustubh Pandey
2023-10-23 11:20 ` Florian Westphal
2023-10-25 17:25 ` Kaustubh Pandey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox