[PATCH] batman-adv: initialize "struct batadv_tvlv_tt_vlan_data"->reserved field

ing to find uninitialized fields in this module. [1] https://syzkaller.appspot.com/bug?id=07f3e6dba96f0eb3cabab986adcd8a58b9bdbe9d Reported-by: syzbot Tested-by: syzbot Signed-off-by: Tetsuo Handa Fixes: ced72933a5e8ab52 ("batman-adv: use CRC32C instead of CRC16 in TT code") Fixes: 7ea7b4a

Re: [PATCH] batman-adv: initialize "struct batadv_tvlv_tt_vlan_data"->reserved field

On 2021/04/05 16:39, Sven Eckelmann wrote: > On Monday, 5 April 2021 07:33:06 CEST Tetsuo Handa wrote: > [...] >> --- >> net/batman-adv/translation-table.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/net/batman-adv/translation-table.c >

[PATCH v2] batman-adv: initialize "struct batadv_tvlv_tt_vlan_data"->reserved field

make the TT CRC logic VLAN specific") moved that field to "struct batadv_tvlv_tt_vlan_data" but left that field uninitialized. [1] https://syzkaller.appspot.com/bug?id=07f3e6dba96f0eb3cabab986adcd8a58b9bdbe9d Reported-by: syzbot Tested-by: syzbot Signed-off-by: Tetsuo Handa Fixes:

BPF: unbounded bpf_map_free_deferred problem

bpf_map_free_deferred from completing? Please see https://lkml.kernel.org/r/CACT4Y+Z+kwPM=WUzJ-e359PWeLLqmF0w4Yxp1spzZ=+j0ek...@mail.gmail.com . On 2021/01/23 7:53, Alexey Kardashevskiy wrote: > > > On 23/01/2021 02:30, Tetsuo Handa wrote: >> On 2021/01/22 22:28, Tetsuo Handa wrote: >>

Re: BPF: unbounded bpf_map_free_deferred problem

On 2021/01/25 8:48, Alexey Kardashevskiy wrote: > > > On 23/01/2021 22:17, Tetsuo Handa wrote: >> On 2021/01/23 12:27, Cong Wang wrote: >>> On Fri, Jan 22, 2021 at 4:42 PM Tetsuo Handa >>> wrote: >>>> >>>> Hello, BPF developers. >&g

[PATCH] Bluetooth: initialize skb_queue_head at l2cap_chan_create()

n_create() immediately after "struct l2cap_chan" is allocated using kzalloc(), let's as well initialize "struct l2cap_chan"->{tx_q,srej_q}.lock spinlocks there. [1] https://syzkaller.appspot.com/bug?extid=fadfba6a911f6bf71842 Reported-and-tested-by: syzbot Signed-off-

Re: [PATCH] mwifiex: don't call del_timer_sync() on uninitialized timer

lled [1]. >> Since mwifiex_usb_prepare_tx_aggr_skb() is calling del_timer() if >> is_hold_timer_set == true, use the same condition for del_timer_sync(). >> >> [1] >> https://syzkaller.appspot.com/bug?id=fdeef9cf7348be8b8ab5b847f2ed993aba8ea7b6 >> >> Reported

[PATCH v2] mwifiex: don't call del_timer_sync() on uninitialized timer

et's use same approach here. [1] https://syzkaller.appspot.com/bug?id=26525f643f454dd7be0078423e3cdb0d57744959 [2] https://lkml.kernel.org/r/ca+asdxmht2gq9hy+ip_bykwxssrewdp3_bafmkncuqj3k+-...@mail.gmail.com Reported-by: syzbot Cc: Ganapathi Bhat Cc: Brian Norris Signed-off-by: Tetsuo Handa --- d

Re: INFO: rcu detected stall in __schedule

I'm not sure whether this is a PPP bug. As of uptime = 484, RCU says that it stalled for 125 seconds. -- [ 484.407032] INFO: rcu_sched self-detected stall on CPU [ 484.412488] 0-...!: (125000 ticks this GP) idle=f3e/1/4611686018427387906 softirq=112858/112858 fqs=0 [ 484.422300] (

Re: WARNING in kernfs_add_one

t previous fault injection messages... >From 7ddcaa3d4327d4f29d11053bd2011bf77ecf72af Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Mon, 7 May 2018 14:19:50 +0900 Subject: [PATCH] driver core: Don't ignore class_dir_create_and_add() failure. syzbot is hitting WARN() at kernfs_add_on

Re: WARNING in add_uevent_var

sg(fd, &msg, 0); return 0; } ---- >From 3eba6541da0c7338e3d71ea83cbc69962923d65e Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Mon, 7 May 2018 15:58:37 +0900 Subject: [PATCH] net: rfkill: Add filename varidity test at rfkill_alloc(). syzbot is hitting WARN() at k

Re: WARNING: refcount bug in should_fail

Eric W. Biederman wrote: > Al Viro writes: > > > On Mon, Apr 02, 2018 at 10:59:34PM +0100, Al Viro wrote: > > > >> FWIW, I'm going through the ->kill_sb() instances, fixing that sort > >> of bugs (most of them preexisting, but I should've checked instead > >> of assuming that everything's fine).

Re: bpf-next boot error: WARNING: workqueue cpumask: online intersect > possible intersect

Please ignore net-next boot error: WARNING: workqueue cpumask: online intersect > possible intersect bpf-next boot error: WARNING: workqueue cpumask: online intersect > possible intersect bpf boot error: WARNING: workqueue cpumask: online intersect > possible intersect net boot error: W

Re: WARNING: refcount bug in should_fail

syzbot wrote: > > On Sun, Mar 4, 2018 at 6:57 AM, Tetsuo Handa > > wrote: > >> Switching from mm to fsdevel, for this report says that put_net(net) in > >> rpc_kill_sb() made net->count < 0 when mount_ns() failed due to > >> register_shrinke

Re: WARNING: refcount bug in should_fail

Dmitry Vyukov wrote: > On Sun, Apr 1, 2018 at 12:32 PM, Dmitry Vyukov wrote: > > On Sun, Mar 4, 2018 at 6:57 AM, Tetsuo Handa > > wrote: > >> Switching from mm to fsdevel, for this report says that put_net(net) in > >> rpc_kill_sb() made net->cou

Re: WARNING: refcount bug in should_fail

Switching from mm to fsdevel, for this report says that put_net(net) in rpc_kill_sb() made net->count < 0 when mount_ns() failed due to register_shrinker() failure. Relevant commits will be commit 9ee332d99e4d5a97 ("sget(): handle failures of register_shrinker()") and commit d91ee87d8d85a080 ("vfs

Re: [PATCH bpf] xdp: Handle device unregister for devmap_hash map type

ler. > > Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by > hashed index") > Reported-by: Tetsuo Handa > Signed-off-by: Toke Høiland-Jørgensen Well, regarding 6f9d451ab1a3, I think that we want explicit "(u64)" cast @@ -97,6 +123,14 @@

[PATCH] net: socket: Always initialize family field at move_addr_to_kernel().

1 [2] https://syzkaller.appspot.com/bug?id=a4bf9e41b7e055c3823fdcd83e8c58ca7270e38f Reported-by: syzbot Reported-by: syzbot Signed-off-by: Tetsuo Handa --- net/socket.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/socket.c b/net/socket.c index 8255f5b..10a780b 100644 --- a/net/socket.c +++ b/net/socket

Re: [PATCH] net: socket: Always initialize family field at move_addr_to_kernel().

On 2019/04/03 5:23, David Miller wrote: > From: Tetsuo Handa > Date: Mon, 1 Apr 2019 23:19:22 +0900 > >> syzbot is reporting uninitialized value at rds_connect [1] and >> rds_bind [2]. This is because syzbot is passing ulen == 0 whereas >> these functions expect

Re: [PATCH] net: socket: Always initialize family field at move_addr_to_kernel().

On 2019/04/04 13:49, David Miller wrote: > From: Tetsuo Handa > Date: Wed, 3 Apr 2019 06:07:40 +0900 > >> On 2019/04/03 5:23, David Miller wrote: >>> Please fix RDS and other protocols to examine the length properly >>> instead. >> >> Do you pref

Re: [PATCH] net: socket: Always initialize family field at move_addr_to_kernel().

Paul Moore wrote: > > + /* > > +* Nothing more to do if valid length is too short to check > > +* address->sa_family. > > +*/ > > + if (addrlen < offsetofend(struct sockaddr, sa_family)) > > + goto out; > > SELinux already checks the address length

[PATCH 1/9] net/rds: Check address length before reading address family

tps://syzkaller.appspot.com/bug?id=f4e61c010416c1e6f0fa3ffe247561b60a50ad71 [2] https://syzkaller.appspot.com/bug?id=a4bf9e41b7e055c3823fdcd83e8c58ca7270e38f Reported-by: syzbot Reported-by: syzbot Signed-off-by: Tetsuo Handa --- net/rds/af_rds.c | 3 +++ net/rds/bind.c | 2 ++ 2 files changed, 5 inserti

[PATCH 2/9] mISDN: Check address length before reading address family

KMSAN will complain if valid address length passed to bind() is shorter than sizeof("struct sockaddr_mISDN"->family) bytes. Signed-off-by: Tetsuo Handa --- drivers/isdn/mISDN/socket.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/isdn/mISDN/socke

[PATCH 3/9] sctp: Check address length before reading srx_service field

KMSAN will complain if valid address length passed to connect() is shorter than sizeof("struct sockaddr"->sa_family) bytes. Signed-off-by: Tetsuo Handa --- net/sctp/socket.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/sctp/socket.c b/net/sctp/s

[PATCH 4/9] net: netlink: Check address length before reading groups field

KMSAN will complain if valid address length passed to bind() is shorter than sizeof(struct sockaddr_nl) bytes. Signed-off-by: Tetsuo Handa --- net/netlink/af_netlink.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index

[PATCH 5/9] rxrpc: Check address length before reading srx_service field

KMSAN will complain if valid address length passed to bind() is shorter than sizeof(struct sockaddr_rxrpc) bytes. Signed-off-by: Tetsuo Handa --- net/rxrpc/af_rxrpc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c index

[PATCH 7/9] llc: Check address length before reading address field

KMSAN will complain if valid address length passed to bind() is shorter than sizeof(struct sockaddr_llc) bytes. Signed-off-by: Tetsuo Handa --- net/llc/af_llc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c index b99e73a7e7e0

[PATCH 6/9] Bluetooth: Check address length before reading address field

KMSAN will complain if valid address length passed to bind() is shorter than sizeof(struct sockaddr_sco) bytes. Signed-off-by: Tetsuo Handa --- net/bluetooth/sco.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c index

[PATCH 8/9] bpf: Check address length before reading address family

KMSAN will complain if valid address length passed to bpf_bind() is shorter than sizeof("struct sockaddr"->sa_family) bytes. Signed-off-by: Tetsuo Handa --- net/core/filter.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/core/filter.c b/net/core/filter.c index

[PATCH 9/9] udpv6: Check address length before reading address family

ase, we want a comment why we don't need to check valid address length here.) Signed-off-by: Tetsuo Handa --- net/ipv6/udp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c index d538fafaf4a9..2464fba569b4 100644 --- a/net/ipv6/udp.c +++ b/net/ipv6/udp

Re: [PATCH 3/9] sctp: Check address length before reading srx_service field

On 2019/04/12 20:12, Neil Horman wrote: > On Fri, Apr 12, 2019 at 07:53:10PM +0900, Tetsuo Handa wrote: >> KMSAN will complain if valid address length passed to connect() is shorter >> than sizeof("struct sockaddr"->sa_family) bytes. >> >> Signed-off-by: Te

Re: [PATCH 5/9] rxrpc: Check address length before reading srx_service field

On 2019/04/12 21:18, David Howells wrote: > Tetsuo Handa wrote: > >> KMSAN will complain if valid address length passed to bind() is shorter >> than sizeof(struct sockaddr_rxrpc) bytes. > > Do you want me to add this to my rxrpc-fixes branch? > Yes, please. > David >

Re: [PATCH 3/9] sctp: Check address length before reading srx_service field

On 2019/04/12 20:21, Tetsuo Handa wrote: > On 2019/04/12 20:12, Neil Horman wrote: >> On Fri, Apr 12, 2019 at 07:53:10PM +0900, Tetsuo Handa wrote: >>> KMSAN will complain if valid address length passed to connect() is shorter >>> than sizeof("struct sockaddr"-

Re: [PATCH 9/9] udpv6: Check address length before reading address family

On 2019/04/13 1:49, Andrey Ignatov wrote: > Such a check wasn't added since it's already checked in > inet_dgram_connect, the only place where udpv6_pre_connect is called: > > int inet_dgram_connect(struct socket *sock, struct sockaddr *uaddr, > int addr_len, int flags)

[PATCH] mwifiex: don't call del_timer_sync() on uninitialized timer

condition for del_timer_sync(). [1] https://syzkaller.appspot.com/bug?id=fdeef9cf7348be8b8ab5b847f2ed993aba8ea7b6 Reported-by: syzbot Cc: Ganapathi Bhat Signed-off-by: Tetsuo Handa --- A patch from Ganapathi Bhat ( https://patchwork.kernel.org/patch/10990275/ ) is stalling at https

[PATCH] net: fddi: skfp: Remove addr_to_string().

kbuild test robot found that addr_to_string() is available only when DEBUG is defined. And I found that what that function is doing is what %pM will do. Thus, replace %s with %pM and remove thread-unsafe addr_to_string() function. Reported-by: kbuild test robot Signed-off-by: Tetsuo Handa

[PATCH] tipc: fix shutdown() of connectionless socket

by setting sk->sk_shutdown to SHUTDOWN_MASK (like inet_shutdown() does) when the socket is connectionless. [1] https://syzkaller.appspot.com/bug?id=3fe51d307c1f0a845485cf1798aa059d12bf18b2 Reported-by: syzbot Signed-off-by: Tetsuo Handa --- net/tipc/socket.c | 9 ++--- 1 file changed, 6

[PATCH v2] tipc: fix shutdown() of connectionless socket

sk->sk_shutdown to SHUTDOWN_MASK (like inet_shutdown() does) when the socket is connectionless. [1] https://syzkaller.appspot.com/bug?id=3fe51d307c1f0a845485cf1798aa059d12bf18b2 Reported-by: syzbot Signed-off-by: Tetsuo Handa --- net/tipc/socket.c | 9 ++--- 1 file changed, 6 insertions

Re: [PATCH] tipc: fix shutdown() of connectionless socket

On 2020/09/03 20:31, Wouter Verhelst wrote: > So. > > On Wed, Sep 02, 2020 at 08:09:54PM +0900, Tetsuo Handa wrote: >> syzbot is reporting hung task at nbd_ioctl() [1], for there are two >> problems regarding TIPC's connectionless socket's shutdown() operation. &

Re: [PATCH v2] tipc: fix shutdown() of connectionless socket

Hello, Parthasarathy. I have a question regarding commit 6f00089c7372ba97 ("tipc: remove SS_DISCONNECTING state"). That commit added sk->sk_shutdown = SEND_SHUTDOWN; into tipc_shutdown(). What is the reason you chose SEND_SHUTDOWN despite how == SHUT_RDWR ? Since Wouter commented that

[PATCH] tipc: fix shutdown() of connection oriented socket

affect all processes sharing that socket, unconditionally setting sk->sk_shutdown to SHUTDOWN_MASK will be the right behavior. Signed-off-by: Tetsuo Handa --- net/tipc/socket.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/net/tipc/socket.c b/net/tipc/socket.c index

Re: INFO: rcu detected stall in ndisc_alloc_skb

Dmitry Vyukov wrote: > On Sun, Jan 6, 2019 at 2:47 PM Tetsuo Handa > wrote: > > > > On 2019/01/06 22:24, Dmitry Vyukov wrote: > > >> A report at 2019/01/05 10:08 from "no output from test machine (2)" > > >> ( https://syzkaller.appspot.com/t

Re: INFO: rcu detected stall in ndisc_alloc_skb

On 2019/01/19 21:16, Dmitry Vyukov wrote: >> The question for me is, whether sysbot can detect hash collision with >> different >> syz-program lines before writing the hash value to /dev/kmsg, and retry by >> modifying >> syz-program lines in order to get a new hash value until collision is >> a

Re: INFO: rcu detected stall in ndisc_alloc_skb

On 2019/01/20 22:30, Dmitry Vyukov wrote: >> The first messages I want to look at is kernel output. Then, I look at >> syz-program lines as needed. But current "a self-contained file" is >> hard to find kernel output. > > I think everybody looks at kernel crash first, that's why we provide > kerne

Re: INFO: rcu detected stall in ndisc_alloc_skb

On 2018/12/31 16:49, Dmitry Vyukov wrote: > On Mon, Dec 31, 2018 at 8:42 AM syzbot > wrote: >> >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:ef4ab8447aa2 selftests: bpf: install script with_addr.sh >> git tree: bpf-next >> console output: https://syzkaller.appspo

Re: INFO: rcu detected stall in ndisc_alloc_skb

On 2018/12/31 17:24, Dmitry Vyukov wrote: >>> Since this involves OOMs and looks like a one-off induced memory corruption: >>> >>> #syz dup: kernel panic: corrupted stack end in wb_workfn >>> >> >> Why? >> >> RCU stall in this case is likely to be latency caused by flooding of >> printk(). > > Ju

Re: INFO: rcu detected stall in ndisc_alloc_skb

On 2019/01/03 2:06, Tetsuo Handa wrote: > On 2018/12/31 17:24, Dmitry Vyukov wrote: >>>> Since this involves OOMs and looks like a one-off induced memory >>>> corruption: >>>> >>>> #syz dup: kernel panic: corrupted stack end in wb_workfn >>

Re: INFO: rcu detected stall in ndisc_alloc_skb

On 2019/01/06 22:24, Dmitry Vyukov wrote: >> A report at 2019/01/05 10:08 from "no output from test machine (2)" >> ( https://syzkaller.appspot.com/text?tag=CrashLog&x=1700726f40 ) >> says that there are flood of memory allocation failure messages. >> Since continuous memory allocation failure

Re: bpf: Massive skbuff_head_cache memory leak?

Hello, Alexei and Daniel. Can you show us how to run testcases you are testing? On 2018/09/22 22:25, Tetsuo Handa wrote: > Hello. > > syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git > / net-next.git trees. > > INFO: rcu

[PATCH] tipc: Disable preemption when calling send_msg method.

bug?id=dc6352b92862eb79373fe03fdf9af5928753e057 Reported-by: syzbot+1a68504d96cd17b33...@syzkaller.appspotmail.com Signed-off-by: Tetsuo Handa --- net/tipc/bearer.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c index 34ca7b789eba..e5cf91665881 100644 --- a/net/tipc/bearer.c +++ b/ne

Re: [PATCH net] tipc: block BH before using dst_cache

On Fri, May 22, 2020 at 2:30 AM Eric Dumazet wrote: > dst_cache_get() documents it must be used with BH disabled. Since the report was complaining about preemption at this_cpu_ptr(), and "#syz test" request with my preemption-disable patch no longer complained, I didn't realize that it is docum

Re: linux-next: umh: fix processed error when UMH_WAIT_PROC is used seems to break linux bridge on s390x (bisected)

On 2020/07/01 19:08, Christian Borntraeger wrote: > > > On 30.06.20 19:57, Luis Chamberlain wrote: >> On Fri, Jun 26, 2020 at 02:54:10AM +, Luis Chamberlain wrote: >>> On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote: On 24.06.20 20:32, Christian Borntraege

Re: linux-next: umh: fix processed error when UMH_WAIT_PROC is used seems to break linux bridge on s390x (bisected)

On 2020/07/01 22:53, Luis Chamberlain wrote: >> Well, it is not br_stp_call_user() but br_stp_start() which is expecting >> to set sub_info->retval for both KWIFEXITED() case and KWIFSIGNALED() case. >> That is, sub_info->retval needs to carry raw value (i.e. without "umh: fix >> processed error wh

Re: linux-next: umh: fix processed error when UMH_WAIT_PROC is used seems to break linux bridge on s390x (bisected)

On 2020/07/02 0:38, Luis Chamberlain wrote: > @@ -156,6 +156,18 @@ static void call_usermodehelper_exec_sync(struct > subprocess_info *sub_info) >*/ > if (KWIFEXITED(ret)) > sub_info->retval = KWEXITSTATUS(ret); > + /* > +

Re: linux-next: umh: fix processed error when UMH_WAIT_PROC is used seems to break linux bridge on s390x (bisected)

On 2020/07/03 4:46, Luis Chamberlain wrote: > On Thu, Jul 02, 2020 at 01:26:53PM +0900, Tetsuo Handa wrote: >> On 2020/07/02 0:38, Luis Chamberlain wrote: >>> @@ -156,6 +156,18 @@ static void call_usermodehelper_exec_sync(struct >>>

[PATCH v2] lockdep: Fix fs_reclaim warning.

>From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Thu, 8 Feb 2018 10:35:35 +0900 Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep warnings. WARN

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

Nikolay Borisov wrote: > I think I've hit another incarnation of that one. The call stack is: > http://paste.opensuse.org/3f22d013 > > The cleaned up callstack of all the ? entries look like: > > __lock_acquire+0x2d8a/0x4b70 > lock_acquire+0x110/0x330 > kmem_cache_alloc+0x29/0x2c0 > __clear_exten

Re: [PATCH v2] lockdep: Fix fs_reclaim warning.

Peter, are you OK with this patch? Tetsuo Handa wrote: > From 361d37a7d36978020dfb4c11ec1f4800937ccb68 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Thu, 8 Feb 2018 10:35:35 +0900 > Subject: [PATCH v2] lockdep: Fix fs_reclaim warning. > > Dave Jones reported fs_reclai

Re: [4.15-rc9] fs_reclaim lockdep trace

Linus Torvalds wrote: > On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >> > Just triggered this on a server I was rsync'ing to. >> >> Actually, I can trigger this really easily, even with an rsync from one >> disk to another. Tho

Re: [4.15-rc9] fs_reclaim lockdep trace

On 2018/01/28 10:16, Tetsuo Handa wrote: > Linus Torvalds wrote: >> On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >>> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >>> > Just triggered this on a server I was rsync'ing to. >>> &g

Re: [4.15-rc9] fs_reclaim lockdep trace

Dave, would you try below patch? >From cae2cbf389ae3cdef1b492622722b4aeb07eb284 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Sun, 28 Jan 2018 14:17:14 +0900 Subject: [PATCH] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep warni

Re: kernel panic: Out of memory and no killable processes... (2)

syzbot wrote: > syzbot hit the following crash on net-next commit > 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +) > Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed' > > C reproducer is attached. > syzkaller reproducer is attached. > Raw console output is a

Re: [4.15-rc9] fs_reclaim lockdep trace

Peter Zijlstra wrote: > On Sun, Jan 28, 2018 at 02:55:28PM +0900, Tetsuo Handa wrote: > > This warning seems to be caused by commit d92a8cfcb37ecd13 > > ("locking/lockdep: Rework FS_RECLAIM annotation") which moved the > > location of > > > >

Re: [4.15-rc9] fs_reclaim lockdep trace

Peter Zijlstra wrote: > On Mon, Jan 29, 2018 at 08:47:20PM +0900, Tetsuo Handa wrote: > > Peter Zijlstra wrote: > > > On Sun, Jan 28, 2018 at 02:55:28PM +0900, Tetsuo Handa wrote: > > > > This warning seems to be caused by commit d92a8cfcb37ecd13 > > >

[RFC] Allow LSM to use IP address/port number. (was Re: [PATCH 1/1] Add post accept()/recvmsg() hooks.)

quest them. Is this change no problem? Regards. Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]> --- include/linux/security.h | 38 ++ net/socket.c | 40 ++-- security/dummy.c | 11 +-- 3

Re: [RFC] Allow LSM to use IP address/port number.

Hello. Thank you for your comment. David Miller wrote: > I don't think it's such a hot idea to return errors if the > wait_on_sync_kiocb() has returned success. My patch may return errors for non-wait_on_sync_kiocb() case too. Are you saying only wait_on_sync_kiocb() case is bad? If so, could yo

Re: [RFC] Allow LSM to use IP address/port number.

Thank you for your comment. I have a question regarding netfilter infrastructure. I want to filter messages using "task_struct->security". Can the netfilter's queuing to userspace feature get a list of "struct task_struct" who shares a socket that is going to receive incoming messages? My approa

[PATCH] Add packet filtering based on process\'s security context.

able to pick up this datagram will repeat recvmsg() forever, which is a worse side effect. Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]> Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]> include/linux/security.h | 34 +-

[PATCH] Add packet filtering based on process's security context.

s. Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]> Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]> include/linux/security.h | 34 +- net/core/datagram.c | 26 -- net/socket.c |7 +-- securi

Re: [README] away until Dec 3rd

Hello. I have a question. Yesterday, I posted a patch based on 2.6.24-rc3-mm1 that modifies the following files. include/linux/security.h | 34 +- net/core/datagram.c | 26 -- net/socket.c |7 +-- security/dumm

[PATCH net-2.6.25] Add packet filtering based on process's security context.

Hello. Herbert Xu wrote: > On Thu, Nov 22, 2007 at 09:57:14PM +0900, Tetsuo Handa wrote: > > > > But you say that I should make patches based on the net-2.6.25 tree. > > Which tree ("-mm" or "net-2.6.25") should I use for making this patch? > >

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

Hello. James Morris wrote: > From memory, one approach under discussion was to add netfilter hooks to > the transport layer, which could be invoked correctly by each type of > protocol when the target process is selected. > > If this is done for netfilter, then an LSM hook is probably not neede

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

Hello. Thank you for detailed explanation. Samir Bellabes wrote: > By "filtering", you should mean "packets filtring", shouldn't you ? > because this hook is able to deny the accept() syscall for a process, so > it's a kind of "filtring" too. Yes, you are right. > No, it's performed from the use

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

Hello. Samir Bellabes wrote: > at security_socket_accept(), the user only accept the fact that the > application is able to go to sock->ops->accept(). That's the purpose of > this hook. Yes. This hook can't perform filtering. > After, when packet are coming, we can catch them with > libnetfilter_

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

Hello. Thank you for feedback. I have some questions. (1) Your module uses "struct security_operations" and is registered with register_security(). TOMOYO also uses "struct security_operations" and must be registered with register_security(). Can your module and TOMOYO coexist?

Re: [PATCH net-2.6.25] Add packet filtering based on process's securitycontext.

Hello. Patrick McHardy wrote: > No news on that. I'm also a bit sceptical if adding all this complexity > and overhead would really be worth it (considering only netfilter) just > to use the owner match and UID/GID matching. It wouldn't even be > accurate because there is not 1:1 mapping of socket

Re: [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context.

Hello, Samir. Did you receive the following messages? Since these messages were dropped at vger.kernel.org , I'm worrying that you couldn't receive the following messages. Tetsuo Handa wrote: > Hello. > > Samir Bellabes wrote: > > >> what differences between you

Re: [TOMOYO 15/15] LSM expansion for TOMOYO Linux.

Hello. Thank you very much for your time, Paul. Yes, you understood what I wanted to do. TOMOYO Linux's approach: (1) It uses userspace intervention to allow/reject connections and/or packets based on the application's domain. Since existent hooks can't be used for this purpose, I in

[PATCH 1/1] Allow LSM to use IP address/port number.

structure because it is too early to know who the recipant process of the packet is. The only chance to perform ip/port based filtering using ACLs associated with the recipant process of the packet is post-accept() and post-recvmsg(). Therefore, I re-post my patch again. Regards. Signed-off-

Re: [PATCH 1/1] Allow LSM to use IP address/port number.

Hello. Patrick McHardy wrote: > Quoting Tetsuo: > > > So, my approach is not using security context associated with a socket > > > but security context associated with a process. > Isn't the socket context derived from the process context? Not so regarding my case. static int smack_sk_alloc_secu

What does -EIOCBQUEUED do?

Hello. There are several locations that handle -EIOCBQUEUED error code. According to include/linux/errno.h , it seems this code is NFS related and caller will receive completion event later. But I couldn't figure out where is the beginning point and what is happening. What functions are called be

[PATCH net-2.6.25] Add packet filtering based on process's security context.

Hello. This is a repost of a patch submitted at http://lkml.org/lkml/2007/11/19/545 . Current status is that I'm waiting for Samir Bellabes's answer whether we can handle the following example without this patch. Tetsuo Handa wrote: > Hello. > > Samir Bellabes wrote: >

Re: AF_UNIX MSG_PEEK bug?

Hello. Brent Casavant wrote: > However, the program would occasionally get into a situation where > a call to recv(sockfd, &buf, len, MSG_PEEK) returns some number > of bytes less than the requested length, and persists in this state > (i.e. retrying the call continues to return the same amount of

[PATCH net-2.6.25] Add packet filtering based on process's security context.

rocess who receives the incoming packet is not known until a process calls sys_recvmsg(). So, I want to add a LSM hook to give a security module a chance to control after the recipient of the incoming packet is known. Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]> Signed-off-by: Tets

Re: [PATCH net-2.6.25] Add packet filtering based on process\'s security context.

Hello. Casey Schaufler wrote: > Do you have a real situation where two user processes with different > security contexts share a socket? How do you get into that situation, > and is it appropriate to have that situation in your security scheme? > Can this occur without using privilege? I hope suc

Re: [PATCH net-2.6.25] Add packet filtering based on process's security context.

chance to control after the recipient of the incoming packet is known. Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]> Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]> --- include/linux/security.h | 34 +- net/core/datagram.c | 29

Re: [PATCH] vmxnet3: avoid calling pskb_may_pull with interrupts disabled

Neil Horman wrote: > On Mon, Mar 07, 2016 at 03:16:14PM -0500, David Miller wrote: > > From: Neil Horman > > Date: Fri, 4 Mar 2016 13:40:48 -0500 This patch is calling spin_unlock_irqrestore() without spin_lock_irqsave(). In file included from include/linux/seqlock.h:35:0, from

Re: 4.4.3: OOPS when running "stress-ng --sock 5"

Holger Schurig wrote: > So I did an "arm-linux-gnueabihf-objdump -Sgd linux/vmlinux", not sure > if that helps: > > c00972ec <__rmqueue>: > * Do the hard work of removing an element from the buddy allocator. > * Call me with the zone->lock already held. > */ > static struct page *__rmqueue(stru

Re: [PATCH] unix: properly account for FDs passed over unix sockets

before the culprit process is killed (CVE-2013-4312)". Reported-by: Tetsuo Handa Mitigates: CVE-2013-4312 (Linux 2.0+) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[linux-next] NULL pointer dereference in rt6_fill_node

Hello. I'm hitting this with linux-next-20170125. Is this known? [ OK ] Started Show Plymouth Reboot Screen. [ OK ] Stopped PostgreSQL database server. [ OK ] Stopped Dynamic System Tuning Daemon. [ OK ] Stopped target Network. Stopping

[PATCH] netfilter: x_tables: fix kmemcheck warning.

10 [ 367.501792] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 367.502971] NET: Registered protocol family 17 Signed-off-by: Tetsuo Handa --- net/netfilter/x_tables.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index

[PATCH] tcp: use kmalloc() than kmalloc_array().

re is no need to use kmalloc_array(). Since I assume it won't overflow, use kmalloc() than kmalloc_array(). Signed-off-by: Tetsuo Handa --- net/ipv4/inet_hashtables.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashta

Re: [PATCH] tcp: use kmalloc() than kmalloc_array().

Tetsuo Handa wrote: > Commit 095dc8e0c3686d58 ("tcp: fix/cleanup inet_ehash_locks_alloc()") > silently changed from kmalloc() to kmalloc_array(). The latter has > overflow check whereas the former doesn't have. > > If nblocks * locksz might overflow, we need to d

Re: [PATCH] tcp: use kmalloc() than kmalloc_array().

David Miller wrote: > From: Eric Dumazet > Date: Sat, 07 Nov 2015 10:50:07 -0800 > > > I do not feel we should go back to kmalloc() just because > > vmalloc_array() does not exist yet. > > Agreed. > Please change as you like. I was thinking to introduce a helper that does vmalloc() when kmall

[PATCH] tree wide: Use kvfree() than conditional kfree()/vfree()

check and reply if you found problems. Signed-off-by: Tetsuo Handa Acked-by: Michal Hocko Cc: Russell King # arm Cc: # apei Cc: # drbd Cc: # mspec Cc: # drm Cc: Oleg Drokin # lustre Cc: Andreas Dilger # lustre Cc: # coda Cc: # jffs2 Cc: Jan Kara # udf Cc: # xattr Cc: # ipc + mm Cc

Re: [PATCH] ath6kl: Use vmalloc for loading firmware using api1 method

Andy Shevchenko wrote: > On Sat, Nov 28, 2015 at 8:58 PM, Brent Taylor wrote: > > Whats the status on this patch? I don't see it on patchwork anymore > > nor is it in any of the git trees I checked. > > > > You forget to use kvfree() instead of kfree() in core.c. > In addition to that, I think

Re: [patch] cxgb4: memory corruption in debugfs

Dan Carpenter wrote: > You can't use kstrtoul() with an int or it causes memory corruption. > Also j should be unsigned or we have underflow bugs. > > I considered changing "j" to unsigned long but everything fits in a u32. Excuse me, but kstrtouint()'s last argument is not "u32 *" but "unsigned

[2.6.24-mm1] TCP/IPv6 connect() oopses at twothirdsMD4Transform()

Hello. Kernel config is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.24-mm1 2.6.24 works fine. Regards. -- BUG: unable to handle kernel paging request at 25476bec IP: [] twothirdsMD4Transform+0x78/0x37c *pde = Oops: [#1] SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/p

Re: [2.6.24-mm1] TCP/IPv6 connect() oopses at twothirdsMD4Transform()

Hello. > random: revert braindamage that snuck into checkpatch cleanup > > Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> Yes. It solved the oops. Thank you. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info a

[2.6.25-rc1] Locks in udp_recvmsg()?

Hello. I found that udp_recvmsg() in net/ipv4/udp.c for 2.6.25-rc1 calls lock_sock() only when it releases the datagram (i.e. out_free: and csum_copy_err:). Is it correct to call __skb_recv_datagram() without calling lock_sock() when it acquires the datagram (i.e. try_again:)? Regards. -- To uns

  1   2   >