[PATCH] mac802154: Fix uninit-value access in ieee802154_hdr_push_sechdr
The syzkaller reported an issue:
BUG: KMSAN: uninit-value in ieee802154_hdr_push_sechdr
net/ieee802154/header_ops.c:54 [inline]
BUG: KMSAN: uninit-value in ieee802154_hdr_push+0x971/0xb90
net/ieee802154/header_ops.c:108
ieee802154_hdr_push_sechdr net/ieee802154/header_ops.c:54 [inline]
ieee802154_hdr_push+0x971/0xb90 net/ieee802154/header_ops.c:108
ieee802154_header_create+0x9c0/0xc00 net/mac802154/iface.c:396
wpan_dev_hard_header include/net/cfg802154.h:494 [inline]
dgram_sendmsg+0xd1d/0x1500 net/ieee802154/socket.c:677
ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96
sock_sendmsg_nosec net/socket.c:725 [inline]
sock_sendmsg net/socket.c:748 [inline]
sys_sendmsg+0x9c2/0xd60 net/socket.c:2494
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2548
__sys_sendmsg+0x225/0x3c0 net/socket.c:2577
__compat_sys_sendmsg net/compat.c:346 [inline]
__do_compat_sys_sendmsg net/compat.c:353 [inline]
__se_compat_sys_sendmsg net/compat.c:350 [inline]
We found hdr->key_id_mode is uninitialized in mac802154_set_header_security()
which indicates hdr.fc.security_enabled should be 0. However, it is set to be
cb->secen before.
Later, ieee802154_hdr_push_sechdr is invoked, causing KMSAN complains
uninit-value issue.
Since mac802154_set_header_security() sets hdr.fc.security_enabled based on the
variables
ieee802154_sub_if_data *sdata and ieee802154_mac_cb *cb in a collaborative
manner.
Therefore, we should not set security_enabled prior to
mac802154_set_header_security().
Fixed it by removing the line that sets the hdr.fc.security_enabled.
Syzkaller don't provide repro, and I provide a syz repro like:
r0 = syz_init_net_socket$802154_dgram(0x24, 0x2, 0x0)
setsockopt$WPAN_SECURITY(r0, 0x0, 0x1, &(0x7f00)=0x2, 0x4)
setsockopt$WPAN_SECURITY(r0, 0x0, 0x1, &(0x7f80), 0x4)
sendmsg$802154_dgram(r0, &(0x7f000100)={&(0x7f40)={0x24, @short},
0x14, &(0x7fc0)={0x0}}, 0x0)
Fixes: 32edc40ae65c ("ieee802154: change _cb handling slightly")
Signed-off-by: Zhang Shurong
---
net/mac802154/iface.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index c0e2da5072be..c99b6e40a5db 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -368,7 +368,6 @@ static int ieee802154_header_create(struct sk_buff *skb,
memset(, 0, sizeof(hdr.fc));
hdr.fc.type = cb->type;
- hdr.fc.security_enabled = cb->secen;
hdr.fc.ack_request = cb->ackreq;
hdr.seq = atomic_inc_return(>ieee802154_ptr->dsn) & 0xFF;
--
2.30.2
Re: EEVDF/vhost regression (bisected to 86bfbb7ce4f6 sched/fair: Add lag based placement)
On 2023/11/18 15:33, Abel Wu wrote: On 11/17/23 2:58 AM, Tobias Huschle Wrote: TRACE EXCERPT The sched_place trace event was added to the end of the place_entity function and outputs: sev -> sched_entity vruntime sed -> sched_entity deadline sel -> sched_entity vlag avg -> cfs_rq avg_vruntime min -> cfs_rq min_vruntime cpu -> cpu of cfs_rq nr -> cfs_rq nr_running --- CPU 3/KVM-2950 [014] d 576.161432: sched_migrate_task: comm=vhost-2920 pid=2941 prio=120 orig_cpu=15 dest_cpu=14 --> migrates task from cpu 15 to 14 CPU 3/KVM-2950 [014] d 576.161433: sched_place: comm=vhost-2920 pid=2941 sev=4242563284 sed=4245563284 sel=0 avg=4242563284 min=4242563284 cpu=14 nr=0 --> places vhost 2920 on CPU 14 with vruntime 4242563284 CPU 3/KVM-2950 [014] d 576.161433: sched_place: comm= pid=0 sev=16329848593 sed=16334604010 sel=0 avg=16329848593 min=16329848593 cpu=14 nr=0 CPU 3/KVM-2950 [014] d 576.161433: sched_place: comm= pid=0 sev=42560661157 sed=42627443765 sel=0 avg=42560661157 min=42560661157 cpu=14 nr=0 CPU 3/KVM-2950 [014] d 576.161434: sched_place: comm= pid=0 sev=53846627372 sed=54125900099 sel=0 avg=53846627372 min=53846627372 cpu=14 nr=0 CPU 3/KVM-2950 [014] d 576.161434: sched_place: comm= pid=0 sev=86640641980 sed=87255041979 sel=0 avg=86640641980 min=86640641980 cpu=14 nr=0 As the following 2 lines indicates that vhost-2920 is on_rq so can be picked as next, thus its cfs_rq must have at least one entity. While the above 4 lines shows nr=0, so the "comm= pid=0" task(s) can't be in the same cgroup with vhost-2920. Say vhost is in cgroupA, and "comm= pid=0" task with sev=86640641980 is in cgroupB ... This looks like an hierarchy enqueue staff. The temporary trace can get comm and pid of vhost-2920, but failed for the other 4. I think the reason is they were just se but not tasks. Seems this came from the for_each_sched_entity(se) when doing enqueue vhost-2920. And the last one with cfs_rq vruntime=86640641980 might be the root cgroup which was on same level with kworkers. So just from this tiny part of the trace log, there won't be thousands ms level difference. Actually, it might be only 86642125805-86640641980 = 1.5 ms. correct me if there is anything wrong.. Thanks, Honglei CPU 3/KVM-2950 [014] dN... 576.161434: sched_stat_wait: comm=vhost-2920 pid=2941 delay=9958 [ns] CPU 3/KVM-2950 [014] d 576.161435: sched_switch: prev_comm=CPU 3/KVM prev_pid=2950 prev_prio=120 prev_state=S ==> next_comm=vhost-2920 next_pid=2941 next_prio=120 vhost-2920-2941 [014] D 576.161439: sched_waking: comm=vhost-2286 pid=2309 prio=120 target_cpu=008 vhost-2920-2941 [014] d 576.161446: sched_waking: comm=kworker/14:0 pid=6525 prio=120 target_cpu=014 vhost-2920-2941 [014] d 576.161447: sched_place: comm=kworker/14:0 pid=6525 sev=86642125805 sed=86645125805 sel=0 avg=86642125805 min=86642125805 cpu=14 nr=1 --> places kworker 6525 on cpu 14 with vruntime 86642125805 --> which is far larger than vhost vruntime of 4242563284 Here nr=1 means there is another entity in the same cfs_rq with the newly woken kworker, but which? According to the vruntime, I would assume kworker is in cgroupB.
Re: [PATCH v2 3/5] modpost: Extended modversion support
Hi Matthew, kernel test robot noticed the following build errors: [auto build test ERROR on mcgrof/modules-next] [also build test ERROR on powerpc/next powerpc/fixes masahiroy-kbuild/for-next masahiroy-kbuild/fixes linus/master v6.7-rc1 next-20231117] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Matthew-Maurer/export_report-Rehabilitate-script/20231118-110040 base: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git modules-next patch link: https://lore.kernel.org/r/20231118025748.2778044-4-mmaurer%40google.com patch subject: [PATCH v2 3/5] modpost: Extended modversion support config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20231118/202311182118.zjqkg301-...@intel.com/config) compiler: powerpc64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231118/202311182118.zjqkg301-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202311182118.zjqkg301-...@intel.com/ All errors (new ones prefixed by >>): >> arch/powerpc/kernel/module_64.c:25:10: fatal error: string.h: No such file >> or directory 25 | #include | ^~ compilation terminated. vim +25 arch/powerpc/kernel/module_64.c 8 9 #include 10 #include 11 #include 12 #include 13 #include 14 #include 15 #include 16 #include 17 #include 18 #include 19 #include 20 #include 21 #include 22 #include 23 #include 24 #include > 25 #include 26 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH v2 2/5] modules: Refactor + kdoc elf_validity_cached_copy
On Sat, Nov 18, 2023 at 02:54:43AM +, Matthew Maurer wrote: > Functionality is almost identical, just structured for better > documentation and readability. Changes: > > * Section names are checked for *all* non-SHT_NULL sections, not just > SHF_ALLOC sections. We have code that accesses section names of > non-SHF_ALLOC sections (see find_any_sec for example) > * The section name check occurs *before* strcmping on section names. > Previously, it was possible to use an out-of-bounds offset to strcmp > against ".modinfo" or ".gnu.linkonce.this_module" > * strtab is checked for NUL lead+termination and nonzero size > * The symbol table is swept to ensure offsets are inbounds of strtab > > While some of these oversights would normally be worrying, all of the > potentially unverified accesses occur after signature check, and only in > response to a user who can load a kernel module. > > Signed-off-by: Matthew Maurer > --- > kernel/module/internal.h | 7 +- > kernel/module/main.c | 585 +-- > 2 files changed, 444 insertions(+), 148 deletions(-) Again, this needs to be broken into much smaller pieces before we can even review it. Would you want to review this? thanks, greg "think of the reviewers" k-h
Re: [PATCH v2 1/5] export_report: Rehabilitate script
On Sat, Nov 18, 2023 at 02:54:42AM +, Matthew Maurer wrote: > * modules.order has .o files when in a build dir, support this > * .mod.c source layout has changed, update regexes to match > * Add a stage 3, to be more robust against additional .mod.c content When you have to list different things you do in a patch, that is a huge hint that you need to break up your patch into smaller pieces. Remember, each patch can only do one logical thing. I know it feels odd, but it makes it easier to review. This patch, as-is, is nothing that I would be able to take, please make it a series. thanks, greg k-h
