Skip to content

Conversation

shreeya-patel98
Copy link
Collaborator

Commits

    tipc: Fix use-after-free in tipc_conn_close().
    
    jira VULN-80319
    cve CVE-2025-38464
    commit-author Kuniyuki Iwashima <[email protected]>
    commit 667eeab4999e981c96b447a4df5f20bdf5c26f13
    
    syzbot reported a null-ptr-deref in tipc_conn_close() during netns
    dismantle. [0]
    
    tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls
    tipc_conn_close() for each tipc_conn.
    
    The problem is that tipc_conn_close() is called after releasing the
    IDR lock.
    
    At the same time, there might be tipc_conn_recv_work() running and it
    could call tipc_conn_close() for the same tipc_conn and release its
    last ->kref.
    
    Once we release the IDR lock in tipc_topsrv_stop(), there is no
    guarantee that the tipc_conn is alive.
    
    Let's hold the ref before releasing the lock and put the ref after
    tipc_conn_close() in tipc_topsrv_stop().
    
    [0]:
    BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
    Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435
    
    CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: netns cleanup_net
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x1fc/0x2ef lib/dump_stack.c:118
     print_address_description.cold+0x54/0x219 mm/kasan/report.c:256
     kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354
     kasan_report mm/kasan/report.c:412 [inline]
     __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433
     tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
     tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]
     tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722
     ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153
     cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553
     process_one_work+0x864/0x1570 kernel/workqueue.c:2153
     worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
     kthread+0x33f/0x460 kernel/kthread.c:259
     ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
    
    Allocated by task 23:
     kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625
     kmalloc include/linux/slab.h:515 [inline]
     kzalloc include/linux/slab.h:709 [inline]
     tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192
     tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470
     process_one_work+0x864/0x1570 kernel/workqueue.c:2153
     worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
     kthread+0x33f/0x460 kernel/kthread.c:259
     ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
    
    Freed by task 23:
     __cache_free mm/slab.c:3503 [inline]
     kfree+0xcc/0x210 mm/slab.c:3822
     tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]
     kref_put include/linux/kref.h:70 [inline]
     conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155
     process_one_work+0x864/0x1570 kernel/workqueue.c:2153
     worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
     kthread+0x33f/0x460 kernel/kthread.c:259
     ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
    
    The buggy address belongs to the object at ffff888099305a00
     which belongs to the cache kmalloc-512 of size 512
    The buggy address is located 8 bytes inside of
     512-byte region [ffff888099305a00, ffff888099305c00)
    The buggy address belongs to the page:
    page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0
    flags: 0xfff00000000100(slab)
    raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940
    raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                          ^
     ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    

    vsock: Fix transport_* TOCTOU
    
    jira VULN-80685
    cve CVE-2025-38461
    commit-author Michal Luczaj <[email protected]>
    commit 687aa0c5581b8d4aa87fd92973e4ee576b550cdf
    
    Transport assignment may race with module unload. Protect new_transport
    from becoming a stale pointer.
    
    This also takes care of an insecure call in vsock_use_local_transport();
    add a lockdep assert.
    
    BUG: unable to handle page fault for address: fffffbfff8056000
    Oops: Oops: 0000 [#1] SMP KASAN
    RIP: 0010:vsock_assign_transport+0x366/0x600
    Call Trace:
     vsock_connect+0x59c/0xc40
     __sys_connect+0xe8/0x100
     __x64_sys_connect+0x6e/0xc0
     do_syscall_64+0x92/0x1c0
     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    scsi: lpfc: Use memcpy() for BIOS version
    
    jira VULN-72459
    cve CVE-2025-38332
    commit-author Daniel Wagner <[email protected]>
    commit ae82eaf4aeea060bb736c3e20c0568b67c701d7d
    
    The strlcat() with FORTIFY support is triggering a panic because it
    thinks the target buffer will overflow although the correct target
    buffer size is passed in.
    
    Anyway, instead of memset() with 0 followed by a strlcat(), just use
    memcpy() and ensure that the resulting buffer is NULL terminated.
    
    BIOSVersion is only used for the lpfc_printf_log() which expects a
    properly terminated string.
    
    wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds
    
    jira VULN-71889
    cve CVE-2025-38159
    commit-author Alexey Kodanev <[email protected]>
    commit 4c2c372de2e108319236203cce6de44d70ae15cd
    
    Set the size to 6 instead of 2, since 'para' array is passed to
    'rtw_fw_bt_wifi_control(rtwdev, para[0], &para[1])', which reads
    5 bytes:
    
    void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)
    {
        ...
        SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);
        SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));
        ...
        SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));
    
    Detected using the static analysis tool - Svace.
    net_sched: ets: Fix double list add in class with netem as child qdisc
    
    jira VULN-73374
    cve CVE-2025-37914
    commit-author Victor Nogueira <[email protected]>
    commit 1a6d0c00fa07972384b0c308c72db091d49988b6
    
    As described in Gerrard's report [1], there are use cases where a netem
    child qdisc will make the parent qdisc's enqueue callback reentrant.
    In the case of ets, there won't be a UAF, but the code will add the same
    classifier to the list twice, which will cause memory corruption.
    
    In addition to checking for qlen being zero, this patch checks whether
    the class was already added to the active_list (cl_is_active) before
    doing the addition to cater for the reentrant case.
    
    [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/
    

    usb: dwc3: gadget: check that event count does not exceed event buffer length
    
    jira VULN-67718
    cve CVE-2025-37810
    commit-author Frode Isaksen <[email protected]>
    commit 63ccd26cd1f6600421795f6ca3e625076be06c9f
    
    The event count is read from register DWC3_GEVNTCOUNT.
    There is a check for the count being zero, but not for exceeding the
    event buffer length.
    Check that event count does not exceed event buffer length,
    avoiding an out-of-bounds access when memcpy'ing the event.
    Crash log:
    Unable to handle kernel paging request at virtual address ffffffc0129be000
    pc : __memcpy+0x114/0x180
    lr : dwc3_check_event_buf+0xec/0x348
    x3 : 0000000000000030 x2 : 000000000000dfc4
    x1 : ffffffc0129be000 x0 : ffffff87aad60080
    Call trace:
    __memcpy+0x114/0x180
    dwc3_interrupt+0x24/0x34
    

    net/iucv: Avoid explicit cpumask var allocation on stack
    
    jira VULN-44437
    cve CVE-2024-42094
    commit-author Dawei Li <[email protected]>
    commit be4e1304419c99a164b4c0e101c7c2a756b635b9
    
    For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
    variable on stack is not recommended since it can cause potential stack
    overflow.
    
    Instead, kernel code should always use *cpumask_var API(s) to allocate
    cpumask var in config-neutral way, leaving allocation strategy to
    CONFIG_CPUMASK_OFFSTACK.
    
    Use *cpumask_var API(s) to address it.

Kernel Build Log

/mnt/scratch/workspace/ciqlts9_4/ciqlts9_4-lts94-9-2025_07_28__13_26_58/kernel-src-tree
Skipping make mrproper
[TIMER]{MRPROPER}: 0s
x86_64 architecture detected, copying config
'configs/kernel-x86_64-rhel.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-shreeya_ciqlts9_4-dd526148fa88"
Making olddefconfig
#
# configuration written to .config
#
Starting Build
 SYNC    include/config/auto.conf.cmd
 UPD     include/config/kernel.release
mkdir -p /mnt/scratch/workspace/ciqlts9_4/ciqlts9_4-lts94-9-2025_07_28__13_26_58/kernel-src-tree/tools/objtool && make O=/mnt/scratch/workspace/ciqlts9_4/ciqlts9_4-lts94-9-2025_07_28__13_26_58/kernel-src-tree subdir=tools/objtool --no-print-directory -C objtool 
mkdir -p /mnt/scratch/workspace/ciqlts9_4/ciqlts9_4-lts94-9-2025_07_28__13_26_58/kernel-src-tree/tools/bpf/resolve_btfids && make O=/mnt/scratch/workspace/ciqlts9_4/ciqlts9_4-lts94-9-2025_07_28__13_26_58/kernel-src-tree subdir=tools/bpf/resolve_btfids --no-print-directory -C bpf/resolve_btfids 
 UPD     include/generated/utsrelease.h
 INSTALL libsubcmd_headers
 CALL    scripts/atomic/check-atomics.sh
 CC      arch/x86/kernel/asm-offsets.s
 CALL    scripts/checksyscalls.sh
 CC      arch/x86/realmode/init.o
 CC      arch/x86/entry/syscall_64.o
 CC      arch/x86/platform/pvh/enlighten.o
 CC      init/main.o
 <--snip-->
 STRIP   /lib/modules/5.14.0-shreeya_ciqlts9_4-dd526148fa88+/kernel/sound/usb/6fire/snd-usb-6fire.ko
 SIGN    /lib/modules/5.14.0-shreeya_ciqlts9_4-dd526148fa88+/kernel/sound/soc/sof/intel/snd-sof-pci-intel-icl.ko
 SIGN    /lib/modules/5.14.0-shreeya_ciqlts9_4-dd526148fa88+/kernel/sound/usb/6fire/snd-usb-6fire.ko
 DEPMOD  /lib/modules/5.14.0-shreeya_ciqlts9_4-dd526148fa88+
[TIMER]{MODULES}: 9s
Making Install
sh ./arch/x86/boot/install.sh 5.14.0-shreeya_ciqlts9_4-dd526148fa88+ \
   arch/x86/boot/bzImage System.map "/boot"
[TIMER]{INSTALL}: 21s
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-5.14.0-shreeya_ciqlts9_4-dd526148fa88+ and Index to 3
The default is /boot/loader/entries/d84955f323dc42758d1fc6865f813ef4-5.14.0-shreeya_ciqlts9_4-dd526148fa88+.conf with index 3 and kernel /boot/vmlinuz-5.14.0-shreeya_ciqlts9_4-dd526148fa88+
The default is /boot/loader/entries/d84955f323dc42758d1fc6865f813ef4-5.14.0-shreeya_ciqlts9_4-dd526148fa88+.conf with index 3 and kernel /boot/vmlinuz-5.14.0-shreeya_ciqlts9_4-dd526148fa88+
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 0s
[TIMER]{BUILD}: 1620s
[TIMER]{MODULES}: 9s
[TIMER]{INSTALL}: 21s
[TIMER]{TOTAL} 1653s
Rebooting in 10 seconds

kernel-build.log

Testing

shreeya@spatel-dev-bom:~/ciq/workspace/ciqlts9_4/ciqlts9_4-lts94-9-2025_07_28__13_26_58$ grep -a ^ok kselftest-before.log | wc -l
328
shreeya@spatel-dev-bom:~/ciq/workspace/ciqlts9_4/ciqlts9_4-lts94-9-2025_07_28__13_26_58$ grep -a ^ok kselftest-after.log | wc -l
335

kselftest-after.log
kselftest-before.log

jira VULN-44437
cve CVE-2024-42094
commit-author Dawei Li <[email protected]>
commit be4e130

For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.

Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config-neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.

Use *cpumask_var API(s) to address it.

	Signed-off-by: Dawei Li <[email protected]>
	Reviewed-by: Alexandra Winter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit be4e130)
	Signed-off-by: Shreeya Patel <[email protected]>
…r length

jira VULN-67718
cve CVE-2025-37810
commit-author Frode Isaksen <[email protected]>
commit 63ccd26

The event count is read from register DWC3_GEVNTCOUNT.
There is a check for the count being zero, but not for exceeding the
event buffer length.
Check that event count does not exceed event buffer length,
avoiding an out-of-bounds access when memcpy'ing the event.
Crash log:
Unable to handle kernel paging request at virtual address ffffffc0129be000
pc : __memcpy+0x114/0x180
lr : dwc3_check_event_buf+0xec/0x348
x3 : 0000000000000030 x2 : 000000000000dfc4
x1 : ffffffc0129be000 x0 : ffffff87aad60080
Call trace:
__memcpy+0x114/0x180
dwc3_interrupt+0x24/0x34

	Signed-off-by: Frode Isaksen <[email protected]>
Fixes: 72246da ("usb: Introduce DesignWare USB3 DRD Driver")
	Cc: stable <[email protected]>
	Acked-by: Thinh Nguyen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit 63ccd26)
	Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-73374
cve CVE-2025-37914
commit-author Victor Nogueira <[email protected]>
commit 1a6d0c0

As described in Gerrard's report [1], there are use cases where a netem
child qdisc will make the parent qdisc's enqueue callback reentrant.
In the case of ets, there won't be a UAF, but the code will add the same
classifier to the list twice, which will cause memory corruption.

In addition to checking for qlen being zero, this patch checks whether
the class was already added to the active_list (cl_is_active) before
doing the addition to cater for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Fixes: 37d9cf1 ("sched: Fix detection of empty queues in child qdiscs")
	Acked-by: Jamal Hadi Salim <[email protected]>
	Signed-off-by: Victor Nogueira <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 1a6d0c0)
	Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-71889
cve CVE-2025-38159
commit-author Alexey Kodanev <[email protected]>
commit 4c2c372

Set the size to 6 instead of 2, since 'para' array is passed to
'rtw_fw_bt_wifi_control(rtwdev, para[0], &para[1])', which reads
5 bytes:

void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)
{
    ...
    SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);
    SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));
    ...
    SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));

Detected using the static analysis tool - Svace.
Fixes: 4136214 ("rtw88: add BT co-existence support")
	Signed-off-by: Alexey Kodanev <[email protected]>
	Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://patch.msgid.link/[email protected]
(cherry picked from commit 4c2c372)
	Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-72459
cve CVE-2025-38332
commit-author Daniel Wagner <[email protected]>
commit ae82eaf

The strlcat() with FORTIFY support is triggering a panic because it
thinks the target buffer will overflow although the correct target
buffer size is passed in.

Anyway, instead of memset() with 0 followed by a strlcat(), just use
memcpy() and ensure that the resulting buffer is NULL terminated.

BIOSVersion is only used for the lpfc_printf_log() which expects a
properly terminated string.

	Signed-off-by: Daniel Wagner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Reviewed-by: Justin Tee <[email protected]>
	Signed-off-by: Martin K. Petersen <[email protected]>
(cherry picked from commit ae82eaf)
	Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-80685
cve CVE-2025-38461
commit-author Michal Luczaj <[email protected]>
commit 687aa0c

Transport assignment may race with module unload. Protect new_transport
from becoming a stale pointer.

This also takes care of an insecure call in vsock_use_local_transport();
add a lockdep assert.

BUG: unable to handle page fault for address: fffffbfff8056000
Oops: Oops: 0000 [#1] SMP KASAN
RIP: 0010:vsock_assign_transport+0x366/0x600
Call Trace:
 vsock_connect+0x59c/0xc40
 __sys_connect+0xe8/0x100
 __x64_sys_connect+0x6e/0xc0
 do_syscall_64+0x92/0x1c0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Fixes: c0cfa2d ("vsock: add multi-transports support")
	Reviewed-by: Stefano Garzarella <[email protected]>
	Signed-off-by: Michal Luczaj <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 687aa0c)
	Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-80319
cve CVE-2025-38464
commit-author Kuniyuki Iwashima <[email protected]>
commit 667eeab

syzbot reported a null-ptr-deref in tipc_conn_close() during netns
dismantle. [0]

tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls
tipc_conn_close() for each tipc_conn.

The problem is that tipc_conn_close() is called after releasing the
IDR lock.

At the same time, there might be tipc_conn_recv_work() running and it
could call tipc_conn_close() for the same tipc_conn and release its
last ->kref.

Once we release the IDR lock in tipc_topsrv_stop(), there is no
guarantee that the tipc_conn is alive.

Let's hold the ref before releasing the lock and put the ref after
tipc_conn_close() in tipc_topsrv_stop().

[0]:
BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435

CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1fc/0x2ef lib/dump_stack.c:118
 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256
 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354
 kasan_report mm/kasan/report.c:412 [inline]
 __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433
 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165
 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]
 tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722
 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153
 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553
 process_one_work+0x864/0x1570 kernel/workqueue.c:2153
 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
 kthread+0x33f/0x460 kernel/kthread.c:259
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415

Allocated by task 23:
 kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625
 kmalloc include/linux/slab.h:515 [inline]
 kzalloc include/linux/slab.h:709 [inline]
 tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192
 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470
 process_one_work+0x864/0x1570 kernel/workqueue.c:2153
 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
 kthread+0x33f/0x460 kernel/kthread.c:259
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415

Freed by task 23:
 __cache_free mm/slab.c:3503 [inline]
 kfree+0xcc/0x210 mm/slab.c:3822
 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]
 kref_put include/linux/kref.h:70 [inline]
 conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155
 process_one_work+0x864/0x1570 kernel/workqueue.c:2153
 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296
 kthread+0x33f/0x460 kernel/kthread.c:259
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415

The buggy address belongs to the object at ffff888099305a00
 which belongs to the cache kmalloc-512 of size 512
The buggy address is located 8 bytes inside of
 512-byte region [ffff888099305a00, ffff888099305c00)
The buggy address belongs to the page:
page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0
flags: 0xfff00000000100(slab)
raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940
raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                      ^
 ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Fixes: c5fa7b3 ("tipc: introduce new TIPC server infrastructure")
	Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=27169a847a70550d17be
	Signed-off-by: Kuniyuki Iwashima <[email protected]>
	Reviewed-by: Tung Nguyen <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 667eeab)
	Signed-off-by: Shreeya Patel <[email protected]>
Copy link
Collaborator

@bmastbergen bmastbergen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

Copy link
Collaborator

@PlaidCat PlaidCat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants