Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix list corruption in perf_cgroup_switch()<br /> <br /> There&amp;#39;s list corruption on cgrp_cpuctx_list. This happens on the<br /> following path:<br /> <br /> perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list)<br /> cpu_ctx_sched_in<br /> ctx_sched_in<br /> ctx_pinned_sched_in<br /> merge_sched_in<br /> perf_cgroup_event_disable: remove the event from the list<br /> <br /> Use list_for_each_entry_safe() to allow removing an entry during<br /> iteration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: vmscan: remove deadlock due to throttling failing to make progress<br /> <br /> A soft lockup bug in kcompactd was reported in a private bugzilla with<br /> the following visible in dmesg;<br /> <br /> watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479]<br /> <br /> The machine had 256G of RAM with no swap and an earlier failed<br /> allocation indicated that node 0 where kcompactd was run was potentially<br /> unreclaimable;<br /> <br /> Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB<br /> inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB<br /> mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp:<br /> 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB<br /> kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes<br /> <br /> Vlastimil Babka investigated a crash dump and found that a task<br /> migrating pages was trying to drain PCP lists;<br /> <br /> PID: 52922 TASK: ffff969f820e5000 CPU: 19 COMMAND: "kworker/u128:3"<br /> Call Trace:<br /> __schedule<br /> schedule<br /> schedule_timeout<br /> wait_for_completion<br /> __flush_work<br /> __drain_all_pages<br /> __alloc_pages_slowpath.constprop.114<br /> __alloc_pages<br /> alloc_migration_target<br /> migrate_pages<br /> migrate_to_node<br /> do_migrate_pages<br /> cpuset_migrate_mm_workfn<br /> process_one_work<br /> worker_thread<br /> kthread<br /> ret_from_fork<br /> <br /> This failure is specific to CONFIG_PREEMPT=n builds. The root of the<br /> problem is that kcompact0 is not rescheduling on a CPU while a task that<br /> has isolated a large number of the pages from the LRU is waiting on<br /> kcompact0 to reschedule so the pages can be released. While<br /> shrink_inactive_list() only loops once around too_many_isolated, reclaim<br /> can continue without rescheduling if sc-&gt;skipped_deactivate == 1 which<br /> could happen if there was no file LRU and the inactive anon list was not<br /> low.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL<br /> <br /> If we fail to copy the just created file descriptor to userland, we<br /> try to clean up by putting back &amp;#39;fd&amp;#39; and freeing &amp;#39;ib&amp;#39;. The code uses<br /> put_unused_fd() for the former which is wrong, as the file descriptor<br /> was already published by fd_install() which gets called internally by<br /> anon_inode_getfd().<br /> <br /> This makes the error handling code leaving a half cleaned up file<br /> descriptor table around and a partially destructed &amp;#39;file&amp;#39; object,<br /> allowing userland to play use-after-free tricks on us, by abusing<br /> the still usable fd and making the code operate on a dangling<br /> &amp;#39;file-&gt;private_data&amp;#39; pointer.<br /> <br /> Instead of leaving the kernel in a partially corrupted state, don&amp;#39;t<br /> attempt to explicitly clean up and leave this to the process exit<br /> path that&amp;#39;ll release any still valid fds, including the one created<br /> by the previous call to anon_inode_getfd(). Simply return -EFAULT to<br /> indicate the error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/proc: task_mmu.c: don&amp;#39;t read mapcount for migration entry<br /> <br /> The syzbot reported the below BUG:<br /> <br /> kernel BUG at include/linux/page-flags.h:785!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline]<br /> RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744<br /> Call Trace:<br /> page_mapcount include/linux/mm.h:837 [inline]<br /> smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466<br /> smaps_pte_entry fs/proc/task_mmu.c:538 [inline]<br /> smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601<br /> walk_pmd_range mm/pagewalk.c:128 [inline]<br /> walk_pud_range mm/pagewalk.c:205 [inline]<br /> walk_p4d_range mm/pagewalk.c:240 [inline]<br /> walk_pgd_range mm/pagewalk.c:277 [inline]<br /> __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379<br /> walk_page_vma+0x277/0x350 mm/pagewalk.c:530<br /> smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768<br /> smap_gather_stats fs/proc/task_mmu.c:741 [inline]<br /> show_smap+0xc6/0x440 fs/proc/task_mmu.c:822<br /> seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272<br /> seq_read+0x3e0/0x5b0 fs/seq_file.c:162<br /> vfs_read+0x1b5/0x600 fs/read_write.c:479<br /> ksys_read+0x12d/0x250 fs/read_write.c:619<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The reproducer was trying to read /proc/$PID/smaps when calling<br /> MADV_FREE at the mean time. MADV_FREE may split THPs if it is called<br /> for partial THP. It may trigger the below race:<br /> <br /> CPU A CPU B<br /> ----- -----<br /> smaps walk: MADV_FREE:<br /> page_mapcount()<br /> PageCompound()<br /> split_huge_page()<br /> page = compound_head(page)<br /> PageDoubleMap(page)<br /> <br /> When calling PageDoubleMap() this page is not a tail page of THP anymore<br /> so the BUG is triggered.<br /> <br /> This could be fixed by elevated refcount of the page before calling<br /> mapcount, but that would prevent it from counting migration entries, and<br /> it seems overkilling because the race just could happen when PMD is<br /> split so all PTE entries of tail pages are actually migration entries,<br /> and smaps_account() does treat migration entries as mapcount == 1 as<br /> Kirill pointed out.<br /> <br /> Add a new parameter for smaps_account() to tell this entry is migration<br /> entry then skip calling page_mapcount(). Don&amp;#39;t skip getting mapcount<br /> for device private entries since they do track references with mapcount.<br /> <br /> Pagemap also has the similar issue although it was not reported. Fixed<br /> it as well.<br /> <br /> [shy828301@gmail.com: v4]<br /> [nathan@kernel.org: avoid unused variable warning in pagemap_pmd_range()]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: ti: Fix missing sentinel for clk_div_table<br /> <br /> _get_table_maxdiv() tries to access "clk_div_table" array out of bound<br /> defined in phy-j721e-wiz.c. Add a sentinel entry to prevent<br /> the following global-out-of-bounds error reported by enabling KASAN.<br /> <br /> [ 9.552392] BUG: KASAN: global-out-of-bounds in _get_maxdiv+0xc0/0x148<br /> [ 9.558948] Read of size 4 at addr ffff8000095b25a4 by task kworker/u4:1/38<br /> [ 9.565926]<br /> [ 9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 Not tainted 5.16.0-116492-gdaadb3bd0e8d-dirty #360<br /> [ 9.576242] Hardware name: Texas Instruments J721e EVM (DT)<br /> [ 9.581832] Workqueue: events_unbound deferred_probe_work_func<br /> [ 9.587708] Call trace:<br /> [ 9.590174] dump_backtrace+0x20c/0x218<br /> [ 9.594038] show_stack+0x18/0x68<br /> [ 9.597375] dump_stack_lvl+0x9c/0xd8<br /> [ 9.601062] print_address_description.constprop.0+0x78/0x334<br /> [ 9.606830] kasan_report+0x1f0/0x260<br /> [ 9.610517] __asan_load4+0x9c/0xd8<br /> [ 9.614030] _get_maxdiv+0xc0/0x148<br /> [ 9.617540] divider_determine_rate+0x88/0x488<br /> [ 9.622005] divider_round_rate_parent+0xc8/0x124<br /> [ 9.626729] wiz_clk_div_round_rate+0x54/0x68<br /> [ 9.631113] clk_core_determine_round_nolock+0x124/0x158<br /> [ 9.636448] clk_core_round_rate_nolock+0x68/0x138<br /> [ 9.641260] clk_core_set_rate_nolock+0x268/0x3a8<br /> [ 9.645987] clk_set_rate+0x50/0xa8<br /> [ 9.649499] cdns_sierra_phy_init+0x88/0x248<br /> [ 9.653794] phy_init+0x98/0x108<br /> [ 9.657046] cdns_pcie_enable_phy+0xa0/0x170<br /> [ 9.661340] cdns_pcie_init_phy+0x250/0x2b0<br /> [ 9.665546] j721e_pcie_probe+0x4b8/0x798<br /> [ 9.669579] platform_probe+0x8c/0x108<br /> [ 9.673350] really_probe+0x114/0x630<br /> [ 9.677037] __driver_probe_device+0x18c/0x220<br /> [ 9.681505] driver_probe_device+0xac/0x150<br /> [ 9.685712] __device_attach_driver+0xec/0x170<br /> [ 9.690178] bus_for_each_drv+0xf0/0x158<br /> [ 9.694124] __device_attach+0x184/0x210<br /> [ 9.698070] device_initial_probe+0x14/0x20<br /> [ 9.702277] bus_probe_device+0xec/0x100<br /> [ 9.706223] deferred_probe_work_func+0x124/0x180<br /> [ 9.710951] process_one_work+0x4b0/0xbc0<br /> [ 9.714983] worker_thread+0x74/0x5d0<br /> [ 9.718668] kthread+0x214/0x230<br /> [ 9.721919] ret_from_fork+0x10/0x20<br /> [ 9.725520]<br /> [ 9.727032] The buggy address belongs to the variable:<br /> [ 9.732183] clk_div_table+0x24/0x440

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt_ioctl: fix array_index_nospec in vt_setactivate<br /> <br /> array_index_nospec ensures that an out-of-bounds value is set to zero<br /> on the transient path. Decreasing the value by one afterwards causes<br /> a transient integer underflow. vsa.console should be decreased first<br /> and then sanitized with array_index_nospec.<br /> <br /> Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh<br /> Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU<br /> Amsterdam.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup<br /> <br /> ax88179_rx_fixup() contains several out-of-bounds accesses that can be<br /> triggered by a malicious (or defective) USB device, in particular:<br /> <br /> - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds,<br /> causing OOB reads and (on big-endian systems) OOB endianness flips.<br /> - A packet can overlap the metadata array, causing a later OOB<br /> endianness flip to corrupt data used by a cloned SKB that has already<br /> been handed off into the network stack.<br /> - A packet SKB can be constructed whose tail is far beyond its end,<br /> causing out-of-bounds heap data to be considered part of the SKB&amp;#39;s<br /> data.<br /> <br /> I have tested that this can be used by a malicious USB device to send a<br /> bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response<br /> that contains random kernel heap data.<br /> It&amp;#39;s probably also possible to get OOB writes from this on a<br /> little-endian system somehow - maybe by triggering skb_cow() via IP<br /> options processing -, but I haven&amp;#39;t tested that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX<br /> <br /> Commit effa453168a7 ("i2c: i801: Don&amp;#39;t silently correct invalid transfer<br /> size") revealed that ee1004_eeprom_read() did not properly limit how<br /> many bytes to read at once.<br /> <br /> In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the<br /> length to read as an u8. If count == 256 after taking into account the<br /> offset and page boundary, the cast to u8 overflows. And this is common<br /> when user space tries to read the entire EEPROM at once.<br /> <br /> To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already<br /> the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: gpmi: don&amp;#39;t leak PM reference in error path<br /> <br /> If gpmi_nfc_apply_timings() fails, the PM runtime usage counter must be<br /> dropped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mscc: ocelot: fix use-after-free in ocelot_vlan_del()<br /> <br /> ocelot_vlan_member_del() will free the struct ocelot_bridge_vlan, so if<br /> this is the same as the port&amp;#39;s pvid_vlan which we access afterwards,<br /> what we&amp;#39;re accessing is freed memory.<br /> <br /> Fix the bug by determining whether to clear ocelot_port-&gt;pvid_vlan prior<br /> to calling ocelot_vlan_member_del().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Avoid overwriting the copies of clcsock callback functions<br /> <br /> The callback functions of clcsock will be saved and replaced during<br /> the fallback. But if the fallback happens more than once, then the<br /> copies of these callback functions will be overwritten incorrectly,<br /> resulting in a loop call issue:<br /> <br /> clcsk-&gt;sk_error_report<br /> |- smc_fback_error_report() clcsk_error_report() ------------------|<br /> <br /> So this patch fixes the issue by saving these function pointers only<br /> once in the fallback and avoiding overwriting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - get rid of alg_memory_allocated<br /> <br /> alg_memory_allocated does not seem to be really used.<br /> <br /> alg_proto does have a .memory_allocated field, but no<br /> corresponding .sysctl_mem.<br /> <br /> This means sk_has_account() returns true, but all sk_prot_mem_limits()<br /> users will trigger a NULL dereference [1].<br /> <br /> THis was not a problem until SO_RESERVE_MEM addition.<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 1 PID: 3591 Comm: syz-executor153 Not tainted 5.17.0-rc3-syzkaller-00316-gb81b1829e7e3 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:sk_prot_mem_limits include/net/sock.h:1523 [inline]<br /> RIP: 0010:sock_reserve_memory+0x1d7/0x330 net/core/sock.c:1000<br /> Code: 08 00 74 08 48 89 ef e8 27 20 bb f9 4c 03 7c 24 10 48 8b 6d 00 48 83 c5 08 48 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 3c 08 00 74 08 48 89 ef e8 fb 1f bb f9 48 8b 6d 00 4c 89 ff 48<br /> RSP: 0018:ffffc90001f1fb68 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: ffff88814aabc000 RCX: dffffc0000000000<br /> RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff90e18120<br /> RBP: 0000000000000008 R08: dffffc0000000000 R09: fffffbfff21c3025<br /> R10: fffffbfff21c3025 R11: 0000000000000000 R12: ffffffff8d109840<br /> R13: 0000000000001002 R14: 0000000000000001 R15: 0000000000000001<br /> FS: 0000555556e08300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc74416f130 CR3: 0000000073d9e000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> sock_setsockopt+0x14a9/0x3a30 net/core/sock.c:1446<br /> __sys_setsockopt+0x5af/0x980 net/socket.c:2176<br /> __do_sys_setsockopt net/socket.c:2191 [inline]<br /> __se_sys_setsockopt net/socket.c:2188 [inline]<br /> __x64_sys_setsockopt+0xb1/0xc0 net/socket.c:2188<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fc7440fddc9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffe98f07968 EFLAGS: 00000246 ORIG_RAX: 0000000000000036<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc7440fddc9<br /> RDX: 0000000000000049 RSI: 0000000000000001 RDI: 0000000000000004<br /> RBP: 0000000000000000 R08: 0000000000000004 R09: 00007ffe98f07990<br /> R10: 0000000020000000 R11: 0000000000000246 R12: 00007ffe98f0798c<br /> R13: 00007ffe98f079a0 R14: 00007ffe98f079e0 R15: 0000000000000000<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:sk_prot_mem_limits include/net/sock.h:1523 [inline]<br /> RIP: 0010:sock_reserve_memory+0x1d7/0x330 net/core/sock.c:1000<br /> Code: 08 00 74 08 48 89 ef e8 27 20 bb f9 4c 03 7c 24 10 48 8b 6d 00 48 83 c5 08 48 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 3c 08 00 74 08 48 89 ef e8 fb 1f bb f9 48 8b 6d 00 4c 89 ff 48<br /> RSP: 0018:ffffc90001f1fb68 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: ffff88814aabc000 RCX: dffffc0000000000<br /> RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff90e18120<br /> RBP: 0000000000000008 R08: dffffc0000000000 R09: fffffbfff21c3025<br /> R10: fffffbfff21c3025 R11: 0000000000000000 R12: ffffffff8d109840<br /> R13: 0000000000001002 R14: 0000000000000001 R15: 0000000000000001<br /> FS: 0000555556e08300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc74416f130 CR3: 0000000073d9e000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000