On 03/16/2018 07:25 AM, Kees Cook wrote:
> As part of removing VLAs from the kernel[1], we want to build with -Wvla,
> but it is overly pessimistic and only accepts constant expressions for
> stack array sizes, instead of also constant values. The max() macro
> triggers the warning, so this refac
On 09/27/2017 04:26 PM, Arnd Bergmann wrote:
> On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin
> wrote:
>>
>>
>> On 09/26/2017 09:47 AM, Arnd Bergmann wrote:
>>> On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote:
>
>>> + ret = __builtin_st
ow_bug.cgi?id=81715)
> and a workaround for older compilers, which means that KASAN_EXTRA is
> now just as bad as before and will lead to an instant stack overflow in
> a few extreme cases.
>
> This reverts parts of commit commit 3f181b4 ("lib/Kconfig.debug: disable
> -Wframe-larger-than warnings with KASAN=y").
>
> Signed-off-by: Arnd Bergmann
Acked-by: Andrey Ryabinin
On 09/26/2017 09:47 AM, Arnd Bergmann wrote:
> On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote:
>> On Mon, Sep 25, 2017 at 7:41 AM, David Laight
>> wrote:
>>> From: Arnd Bergmann
Sent: 22 September 2017 22:29
>>> ...
It seems that this is triggered in part by using strlcpy(), w
On 07/18/2017 09:47 AM, Ryan Hsu wrote:
> On 07/11/2017 06:19 PM, Igor Mitsyanko wrote:
>
>> On 07/11/2017 10:28 AM, Andrey Ryabinin wrote:
>>>
>>> It gave me this:
>>>
>>> [118648.825347] #1 quota too big 72 64 16
>>> [11
On 07/11/2017 12:24 AM, Ryan Hsu wrote:
> On 07/04/2017 08:59 AM, Andrey Ryabinin wrote:
>
>> On 07/04/2017 04:49 PM, Kalle Valo wrote:
>>> Andrey Ryabinin writes:
>>>
>>>> I occasionally hit WARN_ON_ONCE(work > weight); in
On 07/04/2017 04:49 PM, Kalle Valo wrote:
> Andrey Ryabinin writes:
>
>> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a
>> laptop with ath10k card.
>>
>>
>> [37207.593370] [ cut here ]
>> [37207.593380] WAR
I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a laptop with
ath10k card.
[37207.593370] [ cut here ]
[37207.593380] WARNING: CPU: 0 PID: 7 at ../net/core/dev.c:5274
net_rx_action+0x258/0x360
[37207.593381] Modules linked in: snd_hda_codec_realtek snd_
On 06/16/2017 06:41 PM, Arnd Bergmann wrote:
> On Fri, Jun 16, 2017 at 3:02 PM, Greg Kroah-Hartman
> wrote:
>> On Fri, Jun 16, 2017 at 02:01:57PM +0200, Arnd Bergmann wrote:
>>> On Thu, Jun 15, 2017 at 6:53 AM, Greg Kroah-Hartman
>>> wrote:
On Thu, Jun 15, 2017 at 06:52:21AM +0200, Greg Kroa
> gfp_flags or in_interrupt() is true. There is no such known context, but let's
> play it safe and make __alloc_pages_direct_compact() robust for cases where
> PF_MEMALLOC is already set.
>
> Fixes: a8161d1ed609 ("mm, page_alloc: restructure direct compacti
On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
> When CONFIG_KASAN is set, we can run into some code that uses incredible
> amounts of kernel stack:
>
> drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes
> is larger than 2048 bytes [-Werror=frame-larger-than=]
> drivers/
On 03/03/2017 05:54 PM, Arnd Bergmann wrote:
> On Fri, Mar 3, 2017 at 3:20 PM, Andrey Ryabinin
> wrote:
>>
>>
>> On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
>>> When CONFIG_KASAN is enabled, we have several functions that use rather
>>> large kernel
On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 97d62c2da6c2..27c838c40a36 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -216,10 +216,9 @@ config ENABLE_MUST_CHECK
> config FRAME_WARN
> int "Warn for stack fram
On 03/02/2017 07:38 PM, Arnd Bergmann wrote:
> When CONFIG_KASAN is enabled, we have several functions that use rather
> large kernel stacks, e.g.
>
> drivers/isdn/hardware/eicon/message.c: In function 'group_optimization':
> drivers/isdn/hardware/eicon/message.c:14841:1: warning: the frame size
On 02/21/2017 09:24 PM, David Miller wrote:
> From: David Miller
> Date: Tue, 21 Feb 2017 13:23:51 -0500 (EST)
>
>> From: Andrey Ryabinin
>> Date: Tue, 21 Feb 2017 14:27:40 +0300
>>
>>> DCCP doesn't purge timewait sockets on network namespace shutdown.
D_STATS_BH")
Reported-by: Dmitry Vyukov
Signed-off-by: Andrey Ryabinin
Acked-by: Arnaldo Carvalho de Melo
---
Changes since v1:
- Rebased on top the -next
- Added Fixes/Acked tags.
net/dccp/ipv4.c | 6 ++
net/dccp/ipv6.c | 6 ++
2 files changed, 12 insertions(+)
diff --git a/net/dc
On 02/21/2017 04:43 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 21, 2017 at 02:27:40PM +0300, Andrey Ryabinin escreveu:
>> DCCP doesn't purge timewait sockets on network namespace shutdown.
>> So, after net namespace destroyed we could still have an active timer
>&
_work+0x419/0xbb0
worker_thread+0x92/0x850
kthread+0x192/0x1e0
ret_from_fork+0x2e/0x40
Add .exit_batch hook to dccp_v4_ops()/dccp_v6_ops() which will purge
timewait sockets on net namespace destruction and prevent above issue.
Reported-by: Dmitry Vyukov
Signed-off-by: Andrey Rya
2017-02-08 16:10 GMT+03:00 Arnd Bergmann :
> On Wed, Feb 8, 2017 at 1:24 PM, Johannes Berg
> wrote:
>
>> Btw, what's causing this to start with? Can't the compiler reuse the
>> stack places?
>
> I have no idea. It's trying to find out of bounds accesses for
> objects on the stack, so maybe it gi
2016-08-23 18:36 GMT+03:00 Eric Dumazet :
> On Tue, 2016-08-23 at 08:05 -0700, Joe Perches wrote:
>
>> A compiler does not have a standards based requirement to
>> initialize arbitrary padding bytes.
>>
>> I believe gcc always does zero all padding anyway.
>
> I would not worry for kernel code, bec
e_lock(). So concurrent setsockopt() and shutdown() may lead
to corrupting these bits.
Fix this by moving ->sk_shutdown bits out of bitfield into a separate byte.
This will not change the 'struct sock' size since ->sk_shutdown moved into
previously unused 16-bit hole.
Signed-off-by
e_lock(). So concurrent setsockopt() and shutdown() may lead
to corrupting these bits.
Fix this by moving ->sk_shutdown bits out of bitfield into a separate byte.
This will not change the 'struct sock' size since ->sk_shutdown moved into
previously unused 16-bit hole.
Signed-off-by
On 05/18/2016 04:03 PM, Eric Dumazet wrote:
> On Wed, 2016-05-18 at 15:03 +0300, Andrey Ryabinin wrote:
>> ->sk_shutdown bits share one bitfield with some other bits in sock struct,
>> such as ->sk_no_check_[r,t]x, ->sk_userlocks ...
>> sock_setsockopt() may writ
On 05/18/2016 01:38 PM, Hannes Frederic Sowa wrote:
> On 18.05.2016 12:14, Andrey Ryabinin wrote:
>> ->sk_shutdown bits share one bitfield with some other bits in sock struct,
>> such as ->sk_no_check_[r,t]x, ->sk_userlocks ...
>> sock_setsockopt() may write to
e_lock(). So concurrent setsockopt() and shutdown() may lead
to corrupting these bits.
Fix that by protecting writes to ->sk_shutdown with lock_sock()
Signed-off-by: Andrey Ryabinin
---
net/unix/af_unix.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/net/unix/af_unix.c b/net/unix/
e_lock(). So concurrent setsockopt() and shutdown() may lead
to corrupting these bits.
Fix this by moving ->sk_shutdown bits out of bitfield into a separate byte.
This will not change the 'struct sock' size since ->sk_shutdown moved into
previously unused 16-bit hole.
Signed-off-by
[IPV6] ADDRCONF: Support RFC3484 configurable address
selection policy table.")
Signed-off-by: Andrey Ryabinin
---
net/ipv6/addrlabel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/addrlabel.c b/net/ipv6/addrlabel.c
index 882124e..a8f6986 100644
--- a/net/ipv6/a
2015-12-03 20:05 GMT+03:00 Johannes Berg :
> On Thu, 2015-12-03 at 18:50 +0300, Andrey Ryabinin wrote:
>> With upcoming CONFIG_UBSAN the following BUILD_BUG_ON in
>> net/mac80211/debugfs.c starts to trigger:
>> BUILD_BUG_ON(hw_flag_names[NUM_IEEE80211_HW_FLAGS] != (voi
array will trigger build failure) except it doesn't fail with CONFIG_UBSAN.
As a bonus this patch slightly decreases size of hw_flag_names array.
Signed-off-by: Andrey Ryabinin
Cc: Johannes Berg
Cc: "David S. Miller"
---
net/mac80211/debugfs.c | 7 ++-
1 file changed, 2 i
29 matches
Mail list logo
