Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Fix a slab-out-of-bounds write bug in udf_find_entry()<br /> <br /> Syzbot reported a slab-out-of-bounds Write bug:<br /> <br /> loop0: detected capacity change from 0 to 2048<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0<br /> fs/udf/namei.c:253<br /> Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610<br /> <br /> CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted<br /> 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS<br /> Google 10/11/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106<br /> print_address_description+0x74/0x340 mm/kasan/report.c:284<br /> print_report+0x107/0x1f0 mm/kasan/report.c:395<br /> kasan_report+0xcd/0x100 mm/kasan/report.c:495<br /> kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189<br /> memcpy+0x3c/0x60 mm/kasan/shadow.c:66<br /> udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253<br /> udf_lookup+0xef/0x340 fs/udf/namei.c:309<br /> lookup_open fs/namei.c:3391 [inline]<br /> open_last_lookups fs/namei.c:3481 [inline]<br /> path_openat+0x10e6/0x2df0 fs/namei.c:3710<br /> do_filp_open+0x264/0x4f0 fs/namei.c:3740<br /> do_sys_openat2+0x124/0x4e0 fs/open.c:1310<br /> do_sys_open fs/open.c:1326 [inline]<br /> __do_sys_creat fs/open.c:1402 [inline]<br /> __se_sys_creat fs/open.c:1396 [inline]<br /> __x64_sys_creat+0x11f/0x160 fs/open.c:1396<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7ffab0d164d9<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89<br /> f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01<br /> f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9<br /> RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180<br /> RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> <br /> Allocated by task 3610:<br /> kasan_save_stack mm/kasan/common.c:45 [inline]<br /> kasan_set_track+0x3d/0x60 mm/kasan/common.c:52<br /> ____kasan_kmalloc mm/kasan/common.c:371 [inline]<br /> __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380<br /> kmalloc include/linux/slab.h:576 [inline]<br /> udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243<br /> udf_lookup+0xef/0x340 fs/udf/namei.c:309<br /> lookup_open fs/namei.c:3391 [inline]<br /> open_last_lookups fs/namei.c:3481 [inline]<br /> path_openat+0x10e6/0x2df0 fs/namei.c:3710<br /> do_filp_open+0x264/0x4f0 fs/namei.c:3740<br /> do_sys_openat2+0x124/0x4e0 fs/open.c:1310<br /> do_sys_open fs/open.c:1326 [inline]<br /> __do_sys_creat fs/open.c:1402 [inline]<br /> __se_sys_creat fs/open.c:1396 [inline]<br /> __x64_sys_creat+0x11f/0x160 fs/open.c:1396<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The buggy address belongs to the object at ffff8880123ff800<br /> which belongs to the cache kmalloc-256 of size 256<br /> The buggy address is located 150 bytes inside of<br /> 256-byte region [ffff8880123ff800, ffff8880123ff900)<br /> <br /> The buggy address belongs to the physical page:<br /> page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000<br /> index:0x0 pfn:0x123fe<br /> head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0<br /> flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)<br /> raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40<br /> raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as allocated<br /> page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(),<br /> pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0<br /> create_dummy_stack mm/page_owner.c:<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom-qmp-combo: fix NULL-deref on runtime resume<br /> <br /> Commit fc64623637da ("phy: qcom-qmp-combo,usb: add support for separate<br /> PCS_USB region") started treating the PCS_USB registers as potentially<br /> separate from the PCS registers but used the wrong base when no PCS_USB<br /> offset has been provided.<br /> <br /> Fix the PCS_USB base used at runtime resume to prevent dereferencing a<br /> NULL pointer on platforms that do not provide a PCS_USB offset (e.g.<br /> SC7180).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix deadlock in nilfs_count_free_blocks()<br /> <br /> A semaphore deadlock can occur if nilfs_get_block() detects metadata<br /> corruption while locating data blocks and a superblock writeback occurs at<br /> the same time:<br /> <br /> task 1 task 2<br /> ------ ------<br /> * A file operation *<br /> nilfs_truncate()<br /> nilfs_get_block()<br /> down_read(rwsem A)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macvlan: fix memory leaks of macvlan_common_newlink<br /> <br /> kmemleak reports memory leaks in macvlan_common_newlink, as follows:<br /> <br /> ip link add link eth0 name .. type macvlan mode source macaddr add<br /> <br /> <br /> kmemleak reports:<br /> <br /> unreferenced object 0xffff8880109bb140 (size 64):<br /> comm "ip", pid 284, jiffies 4294986150 (age 430.108s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z.....<br /> 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x1c7/0x300<br /> [] macvlan_hash_add_source+0x45/0xc0<br /> [] macvlan_changelink_sources+0xd7/0x170<br /> [] macvlan_common_newlink+0x38c/0x5a0<br /> [] macvlan_newlink+0xe/0x20<br /> [] __rtnl_newlink+0x7af/0xa50<br /> [] rtnl_newlink+0x48/0x70<br /> ...<br /> <br /> In the scenario where the macvlan mode is configured as &amp;#39;source&amp;#39;,<br /> macvlan_changelink_sources() will be execured to reconfigure list of<br /> remote source mac addresses, at the same time, if register_netdevice()<br /> return an error, the resource generated by macvlan_changelink_sources()<br /> is not cleaned up.<br /> <br /> Using this patch, in the case of an error, it will execute<br /> macvlan_flush_sources() to ensure that the resource is cleaned up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: Fix an error handling path in mctp_init()<br /> <br /> If mctp_neigh_init() return error, the routes resources should<br /> be released in the error handling path. Otherwise some resources<br /> leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix match incorrectly in dev_args_match_device<br /> <br /> syzkaller found a failed assertion:<br /> <br /> assertion failed: (args-&gt;devid != (u64)-1) || args-&gt;missing, in fs/btrfs/volumes.c:6921<br /> <br /> This can be triggered when we set devid to (u64)-1 by ioctl. In this<br /> case, the match of devid will be skipped and the match of device may<br /> succeed incorrectly.<br /> <br /> Patch 562d7b1512f7 introduced this function which is used to match device.<br /> This function contains two matching scenarios, we can distinguish them by<br /> checking the value of args-&gt;missing rather than check whether args-&gt;devid<br /> and args-&gt;uuid is default value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: fix reserved memory setup<br /> <br /> Currently, RISC-V sets up reserved memory using the "early" copy of the<br /> device tree. As a result, when trying to get a reserved memory region<br /> using of_reserved_mem_lookup(), the pointer to reserved memory regions<br /> is using the early, pre-virtual-memory address which causes a kernel<br /> panic when trying to use the buffer&amp;#39;s name:<br /> <br /> Unable to handle kernel paging request at virtual address 00000000401c31ac<br /> Oops [#1]<br /> Modules linked in:<br /> CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1<br /> Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)<br /> epc : string+0x4a/0xea<br /> ra : vsnprintf+0x1e4/0x336<br /> epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0<br /> gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000<br /> t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20<br /> s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000<br /> a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff<br /> a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff<br /> s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008<br /> s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00<br /> s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002<br /> s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617<br /> t5 : ffffffff812f3618 t6 : ffffffff81203d08<br /> status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d<br /> [] vsnprintf+0x1e4/0x336<br /> [] vprintk_store+0xf6/0x344<br /> [] vprintk_emit+0x56/0x192<br /> [] vprintk_default+0x16/0x1e<br /> [] vprintk+0x72/0x80<br /> [] _printk+0x36/0x50<br /> [] print_reserved_mem+0x1c/0x24<br /> [] paging_init+0x528/0x5bc<br /> [] setup_arch+0xd0/0x592<br /> [] start_kernel+0x82/0x73c<br /> <br /> early_init_fdt_scan_reserved_mem() takes no arguments as it operates on<br /> initial_boot_params, which is populated by early_init_dt_verify(). On<br /> RISC-V, early_init_dt_verify() is called twice. Once, directly, in<br /> setup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly,<br /> very early in the boot process, by parse_dtb() when it calls<br /> early_init_dt_scan_nodes().<br /> <br /> This first call uses dtb_early_va to set initial_boot_params, which is<br /> not usable later in the boot process when<br /> early_init_fdt_scan_reserved_mem() is called. On arm64 for example, the<br /> corresponding call to early_init_dt_scan_nodes() uses fixmap addresses<br /> and doesn&amp;#39;t suffer the same fate.<br /> <br /> Move early_init_fdt_scan_reserved_mem() further along the boot sequence,<br /> after the direct call to early_init_dt_verify() in setup_arch() so that<br /> the names use the correct virtual memory addresses. The above supposed<br /> that CONFIG_BUILTIN_DTB was not set, but should work equally in the case<br /> where it is - unflatted_and_copy_device_tree() also updates<br /> initial_boot_params.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw: Fix segmentation fault at module unload<br /> <br /> Move am65_cpsw_nuss_phylink_cleanup() call to after<br /> am65_cpsw_nuss_cleanup_ndev() so phylink is still valid<br /> to prevent the below Segmentation fault on module remove when<br /> first slave link is up.<br /> <br /> [ 31.652944] Unable to handle kernel paging request at virtual address 00040008000005f4<br /> [ 31.684627] Mem abort info:<br /> [ 31.687446] ESR = 0x0000000096000004<br /> [ 31.704614] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 31.720663] SET = 0, FnV = 0<br /> [ 31.723729] EA = 0, S1PTW = 0<br /> [ 31.740617] FSC = 0x04: level 0 translation fault<br /> [ 31.756624] Data abort info:<br /> [ 31.759508] ISV = 0, ISS = 0x00000004<br /> [ 31.776705] CM = 0, WnR = 0<br /> [ 31.779695] [00040008000005f4] address between user and kernel address ranges<br /> [ 31.808644] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 31.814928] Modules linked in: wlcore_sdio wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce phy_gmii_sel ti_am65_cpsw_nuss(-) sch_fq_codel ipv6<br /> [ 31.828776] CPU: 0 PID: 1026 Comm: modprobe Not tainted 6.1.0-rc2-00012-gfabfcf7dafdb-dirty #160<br /> [ 31.837547] Hardware name: Texas Instruments AM625 (DT)<br /> [ 31.842760] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 31.849709] pc : phy_stop+0x18/0xf8<br /> [ 31.853202] lr : phylink_stop+0x38/0xf8<br /> [ 31.857031] sp : ffff80000a0839f0<br /> [ 31.860335] x29: ffff80000a0839f0 x28: ffff000000de1c80 x27: 0000000000000000<br /> [ 31.867462] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80000a083b98<br /> [ 31.874589] x23: 0000000000000800 x22: 0000000000000001 x21: ffff000001bfba90<br /> [ 31.881715] x20: ffff0000015ee000 x19: 0004000800000200 x18: 0000000000000000<br /> [ 31.888842] x17: ffff800076c45000 x16: ffff800008004000 x15: 000058e39660b106<br /> [ 31.895969] x14: 0000000000000144 x13: 0000000000000144 x12: 0000000000000000<br /> [ 31.903095] x11: 000000000000275f x10: 00000000000009e0 x9 : ffff80000a0837d0<br /> [ 31.910222] x8 : ffff000000de26c0 x7 : ffff00007fbd6540 x6 : ffff00007fbd64c0<br /> [ 31.917349] x5 : ffff00007fbd0b10 x4 : ffff00007fbd0b10 x3 : ffff00007fbd3920<br /> [ 31.924476] x2 : d0a07fcff8b8d500 x1 : 0000000000000000 x0 : 0004000800000200<br /> [ 31.931603] Call trace:<br /> [ 31.934042] phy_stop+0x18/0xf8<br /> [ 31.937177] phylink_stop+0x38/0xf8<br /> [ 31.940657] am65_cpsw_nuss_ndo_slave_stop+0x28/0x1e0 [ti_am65_cpsw_nuss]<br /> [ 31.947452] __dev_close_many+0xa4/0x140<br /> [ 31.951371] dev_close_many+0x84/0x128<br /> [ 31.955115] unregister_netdevice_many+0x130/0x6d0<br /> [ 31.959897] unregister_netdevice_queue+0x94/0xd8<br /> [ 31.964591] unregister_netdev+0x24/0x38<br /> [ 31.968504] am65_cpsw_nuss_cleanup_ndev.isra.0+0x48/0x70 [ti_am65_cpsw_nuss]<br /> [ 31.975637] am65_cpsw_nuss_remove+0x58/0xf8 [ti_am65_cpsw_nuss]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: process: fix kernel info leakage<br /> <br /> thread_struct&amp;#39;s s[12] may contain random kernel memory content, which<br /> may be finally leaked to userspace. This is a security hole. Fix it<br /> by clearing the s[12] array in thread_struct when fork.<br /> <br /> As for kthread case, it&amp;#39;s better to clear the s[12] array as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix memory leaks in __check_func_call<br /> <br /> kmemleak reports this issue:<br /> <br /> unreferenced object 0xffff88817139d000 (size 2048):<br /> comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] __check_func_call+0x316/0x1230<br /> [] check_helper_call+0x172e/0x4700<br /> [] do_check+0x21d8/0x45e0<br /> [] do_check_common+0x767/0xaf0<br /> [] bpf_check+0x43e3/0x5bc0<br /> [] bpf_prog_load+0xf26/0x1940<br /> [] __sys_bpf+0xd2c/0x3650<br /> [] __x64_sys_bpf+0x75/0xc0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The root case here is: In function prepare_func_exit(), the callee is<br /> not released in the abnormal scenario after "state-&gt;curframe--;". To<br /> fix, move "state-&gt;curframe--;" to the very bottom of the function,<br /> right when we free callee and reset frame[] pointer to NULL, as Andrii<br /> suggested.<br /> <br /> In addition, function __check_func_call() has a similar problem. In<br /> the abnormal scenario before "state-&gt;curframe++;", the callee also<br /> should be released by free_func_state().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_transport_sas: Fix error handling in sas_phy_add()<br /> <br /> If transport_add_device() fails in sas_phy_add(), the kernel will crash<br /> trying to delete the device in transport_remove_device() called from<br /> sas_remove_host().<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108<br /> CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : device_del+0x54/0x3d0<br /> lr : device_del+0x37c/0x3d0<br /> Call trace:<br /> device_del+0x54/0x3d0<br /> attribute_container_class_device_del+0x28/0x38<br /> transport_remove_classdev+0x6c/0x80<br /> attribute_container_device_trigger+0x108/0x110<br /> transport_remove_device+0x28/0x38<br /> sas_phy_delete+0x30/0x60 [scsi_transport_sas]<br /> do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas]<br /> device_for_each_child+0x68/0xb0<br /> sas_remove_children+0x40/0x50 [scsi_transport_sas]<br /> sas_remove_host+0x20/0x38 [scsi_transport_sas]<br /> hisi_sas_remove+0x40/0x68 [hisi_sas_main]<br /> hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw]<br /> platform_remove+0x2c/0x60<br /> <br /> Fix this by checking and handling return value of transport_add_device()<br /> in sas_phy_add().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()<br /> <br /> We got a syzkaller problem because of aarch64 alignment fault<br /> if KFENCE enabled. When the size from user bpf program is an odd<br /> number, like 399, 407, etc, it will cause the struct skb_shared_info&amp;#39;s<br /> unaligned access. As seen below:<br /> <br /> BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032<br /> <br /> Use-after-free read at 0xffff6254fffac077 (in kfence-#213):<br /> __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]<br /> arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]<br /> arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]<br /> atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]<br /> __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032<br /> skb_clone+0xf4/0x214 net/core/skbuff.c:1481<br /> ____bpf_clone_redirect net/core/filter.c:2433 [inline]<br /> bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420<br /> bpf_prog_d3839dd9068ceb51+0x80/0x330<br /> bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]<br /> bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53<br /> bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594<br /> bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]<br /> __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]<br /> __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381<br /> <br /> kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512<br /> <br /> allocated by task 15074 on cpu 0 at 1342.585390s:<br /> kmalloc include/linux/slab.h:568 [inline]<br /> kzalloc include/linux/slab.h:675 [inline]<br /> bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191<br /> bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512<br /> bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]<br /> __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]<br /> __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381<br /> __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381<br /> <br /> To fix the problem, we adjust @size so that (@size + @hearoom) is a<br /> multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info<br /> is aligned to a cache line.