Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/qeth: fix use-after-free in hsci<br /> <br /> KASAN found that addr was dereferenced after br2dev_event_work was freed.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0<br /> Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540<br /> CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1<br /> Hardware name: IBM 8561 T01 703 (LPAR)<br /> Workqueue: 0.0.8000_event qeth_l2_br2dev_worker<br /> Call Trace:<br /> [] dump_stack_lvl+0xc6/0xf8<br /> [] print_address_description.constprop.0+0x34/0x2a0<br /> [] print_report+0x110/0x1f8<br /> [] kasan_report+0xfc/0x128<br /> [] qeth_l2_br2dev_worker+0x5ba/0x6b0<br /> [] process_one_work+0x76e/0x1128<br /> [] worker_thread+0x184/0x1098<br /> [] kthread+0x26a/0x310<br /> [] __ret_from_fork+0x8a/0xe8<br /> [] ret_from_fork+0xa/0x40<br /> Allocated by task 108338:<br /> kasan_save_stack+0x40/0x68<br /> kasan_set_track+0x36/0x48<br /> __kasan_kmalloc+0xa0/0xc0<br /> qeth_l2_switchdev_event+0x25a/0x738<br /> atomic_notifier_call_chain+0x9c/0xf8<br /> br_switchdev_fdb_notify+0xf4/0x110<br /> fdb_notify+0x122/0x180<br /> fdb_add_entry.constprop.0.isra.0+0x312/0x558<br /> br_fdb_add+0x59e/0x858<br /> rtnl_fdb_add+0x58a/0x928<br /> rtnetlink_rcv_msg+0x5f8/0x8d8<br /> netlink_rcv_skb+0x1f2/0x408<br /> netlink_unicast+0x570/0x790<br /> netlink_sendmsg+0x752/0xbe0<br /> sock_sendmsg+0xca/0x110<br /> ____sys_sendmsg+0x510/0x6a8<br /> ___sys_sendmsg+0x12a/0x180<br /> __sys_sendmsg+0xe6/0x168<br /> __do_sys_socketcall+0x3c8/0x468<br /> do_syscall+0x22c/0x328<br /> __do_syscall+0x94/0xf0<br /> system_call+0x82/0xb0<br /> Freed by task 540:<br /> kasan_save_stack+0x40/0x68<br /> kasan_set_track+0x36/0x48<br /> kasan_save_free_info+0x4c/0x68<br /> ____kasan_slab_free+0x14e/0x1a8<br /> __kasan_slab_free+0x24/0x30<br /> __kmem_cache_free+0x168/0x338<br /> qeth_l2_br2dev_worker+0x154/0x6b0<br /> process_one_work+0x76e/0x1128<br /> worker_thread+0x184/0x1098<br /> kthread+0x26a/0x310<br /> __ret_from_fork+0x8a/0xe8<br /> ret_from_fork+0xa/0x40<br /> Last potentially related work creation:<br /> kasan_save_stack+0x40/0x68<br /> __kasan_record_aux_stack+0xbe/0xd0<br /> insert_work+0x56/0x2e8<br /> __queue_work+0x4ce/0xd10<br /> queue_work_on+0xf4/0x100<br /> qeth_l2_switchdev_event+0x520/0x738<br /> atomic_notifier_call_chain+0x9c/0xf8<br /> br_switchdev_fdb_notify+0xf4/0x110<br /> fdb_notify+0x122/0x180<br /> fdb_add_entry.constprop.0.isra.0+0x312/0x558<br /> br_fdb_add+0x59e/0x858<br /> rtnl_fdb_add+0x58a/0x928<br /> rtnetlink_rcv_msg+0x5f8/0x8d8<br /> netlink_rcv_skb+0x1f2/0x408<br /> netlink_unicast+0x570/0x790<br /> netlink_sendmsg+0x752/0xbe0<br /> sock_sendmsg+0xca/0x110<br /> ____sys_sendmsg+0x510/0x6a8<br /> ___sys_sendmsg+0x12a/0x180<br /> __sys_sendmsg+0xe6/0x168<br /> __do_sys_socketcall+0x3c8/0x468<br /> do_syscall+0x22c/0x328<br /> __do_syscall+0x94/0xf0<br /> system_call+0x82/0xb0<br /> Second to last potentially related work creation:<br /> kasan_save_stack+0x40/0x68<br /> __kasan_record_aux_stack+0xbe/0xd0<br /> kvfree_call_rcu+0xb2/0x760<br /> kernfs_unlink_open_file+0x348/0x430<br /> kernfs_fop_release+0xc2/0x320<br /> __fput+0x1ae/0x768<br /> task_work_run+0x1bc/0x298<br /> exit_to_user_mode_prepare+0x1a0/0x1a8<br /> __do_syscall+0x94/0xf0<br /> system_call+0x82/0xb0<br /> The buggy address belongs to the object at 00000000fdcea400<br /> which belongs to the cache kmalloc-96 of size 96<br /> The buggy address is located 64 bytes inside of<br /> 96-byte region [00000000fdcea400, 00000000fdcea460)<br /> The buggy address belongs to the physical page:<br /> page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea<br /> flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff)<br /> raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00<br /> raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> Memory state around the buggy address:<br /> 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> 00000000fdcea380: fb fb fb fb fb fb f<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: thunderbolt: fix memory leak in tbnet_open()<br /> <br /> When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in<br /> tb_xdomain_alloc_out_hopid() is not released. Add<br /> tb_xdomain_release_out_hopid() to the error path to release ida.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: avoid use-after-free in ip6_fragment()<br /> <br /> Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.<br /> <br /> It seems to not be always true, at least for UDP stack.<br /> <br /> syzbot reported:<br /> <br /> BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]<br /> BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951<br /> Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618<br /> <br /> CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:284 [inline]<br /> print_report+0x15e/0x45d mm/kasan/report.c:395<br /> kasan_report+0xbf/0x1f0 mm/kasan/report.c:495<br /> ip6_dst_idev include/net/ip6_fib.h:245 [inline]<br /> ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951<br /> __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]<br /> ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206<br /> NF_HOOK_COND include/linux/netfilter.h:291 [inline]<br /> ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227<br /> dst_output include/net/dst.h:445 [inline]<br /> ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161<br /> ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966<br /> udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286<br /> udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313<br /> udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606<br /> inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xd3/0x120 net/socket.c:734<br /> sock_write_iter+0x295/0x3d0 net/socket.c:1108<br /> call_write_iter include/linux/fs.h:2191 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x9ed/0xdd0 fs/read_write.c:584<br /> ksys_write+0x1ec/0x250 fs/read_write.c:637<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fde3588c0d9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9<br /> RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a<br /> RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000<br /> <br /> <br /> Allocated by task 7618:<br /> kasan_save_stack+0x22/0x40 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325<br /> kasan_slab_alloc include/linux/kasan.h:201 [inline]<br /> slab_post_alloc_hook mm/slab.h:737 [inline]<br /> slab_alloc_node mm/slub.c:3398 [inline]<br /> slab_alloc mm/slub.c:3406 [inline]<br /> __kmem_cache_alloc_lru mm/slub.c:3413 [inline]<br /> kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422<br /> dst_alloc+0x14a/0x1f0 net/core/dst.c:92<br /> ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344<br /> ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]<br /> rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]<br /> ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254<br /> pol_lookup_func include/net/ip6_fib.h:582 [inline]<br /> fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121<br /> ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625<br /> ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638<br /> ip6_route_output include/net/ip6_route.h:98 [inline]<br /> ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092<br /> ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222<br /> ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260<br /> udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554<br /> inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665<br /> sock_sendmsg_nosec n<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm/ident_map: Use gbpages only where full GB page should be mapped.<br /> <br /> When ident_pud_init() uses only GB pages to create identity maps, large<br /> ranges of addresses not actually requested can be included in the resulting<br /> table; a 4K request will map a full GB. This can include a lot of extra<br /> address space past that requested, including areas marked reserved by the<br /> BIOS. That allows processor speculation into reserved regions, that on UV<br /> systems can cause system halts.<br /> <br /> Only use GB pages when map creation requests include the full GB page of<br /> space. Fall back to using smaller 2M pages when only portions of a GB page<br /> are included in the request.<br /> <br /> No attempt is made to coalesce mapping requests. If a request requires a<br /> map entry at the 2M (pmd) level, subsequent mapping requests within the<br /> same 1G region will also be at the pmd level, even if adjacent or<br /> overlapping such requests could have been combined to map a full GB page.<br /> Existing usage starts with larger regions and then adds smaller regions, so<br /> this should not have any great consequence.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35<br /> <br /> [WHY &amp; HOW]<br /> Mismatch in DCN35 DML2 cause bw validation failed to acquire unexpected DPP pipe to cause<br /> grey screen and system hang. Remove EnhancedPrefetchScheduleAccelerationFinal value override<br /> to match HW spec.<br /> <br /> (cherry picked from commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac802154: Fix potential RCU dereference issue in mac802154_scan_worker<br /> <br /> In the `mac802154_scan_worker` function, the `scan_req-&gt;type` field was<br /> accessed after the RCU read-side critical section was unlocked. According<br /> to RCU usage rules, this is illegal and can lead to unpredictable<br /> behavior, such as accessing memory that has been updated or causing<br /> use-after-free issues.<br /> <br /> This possible bug was identified using a static analysis tool developed<br /> by myself, specifically designed to detect RCU-related issues.<br /> <br /> To address this, the `scan_req-&gt;type` value is now stored in a local<br /> variable `scan_req_type` while still within the RCU read-side critical<br /> section. The `scan_req_type` is then used after the RCU lock is released,<br /> ensuring that the type value is safely accessed without violating RCU<br /> rules.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: amd-pstate: add check for cpufreq_cpu_get&amp;#39;s return value<br /> <br /> cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it<br /> and return in case of error.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item<br /> <br /> There is no links_num in struct snd_soc_acpi_mach {}, and we test<br /> !link-&gt;num_adr as a condition to end the loop in hda_sdw_machine_select().<br /> So an empty item in struct snd_soc_acpi_link_adr array is required.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix access to uninitialised lock in fc replay path<br /> <br /> The following kernel trace can be triggered with fstest generic/629 when<br /> executed against a filesystem with fast-commit feature enabled:<br /> <br /> INFO: trying to register non-static key.<br /> The code is fine but needs lockdep annotation, or maybe<br /> you didn&amp;#39;t initialize this object before use?<br /> turning off the locking correctness validator.<br /> CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x66/0x90<br /> register_lock_class+0x759/0x7d0<br /> __lock_acquire+0x85/0x2630<br /> ? __find_get_block+0xb4/0x380<br /> lock_acquire+0xd1/0x2d0<br /> ? __ext4_journal_get_write_access+0xd5/0x160<br /> _raw_spin_lock+0x33/0x40<br /> ? __ext4_journal_get_write_access+0xd5/0x160<br /> __ext4_journal_get_write_access+0xd5/0x160<br /> ext4_reserve_inode_write+0x61/0xb0<br /> __ext4_mark_inode_dirty+0x79/0x270<br /> ? ext4_ext_replay_set_iblocks+0x2f8/0x450<br /> ext4_ext_replay_set_iblocks+0x330/0x450<br /> ext4_fc_replay+0x14c8/0x1540<br /> ? jread+0x88/0x2e0<br /> ? rcu_is_watching+0x11/0x40<br /> do_one_pass+0x447/0xd00<br /> jbd2_journal_recover+0x139/0x1b0<br /> jbd2_journal_load+0x96/0x390<br /> ext4_load_and_init_journal+0x253/0xd40<br /> ext4_fill_super+0x2cc6/0x3180<br /> ...<br /> <br /> In the replay path there&amp;#39;s an attempt to lock sbi-&gt;s_bdev_wb_lock in<br /> function ext4_check_bdev_write_error(). Unfortunately, at this point this<br /> spinlock has not been initialized yet. Moving it&amp;#39;s initialization to an<br /> earlier point in __ext4_fill_super() fixes this splat.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix system hang while resume with TBT monitor<br /> <br /> [Why]<br /> Connected with a Thunderbolt monitor and do the suspend and the system<br /> may hang while resume.<br /> <br /> The TBT monitor HPD will be triggered during the resume procedure<br /> and call the drm_client_modeset_probe() while<br /> struct drm_connector connector-&gt;dev-&gt;master is NULL.<br /> <br /> It will mess up the pipe topology after resume.<br /> <br /> [How]<br /> Skip the TBT monitor HPD during the resume procedure because we<br /> currently will probe the connectors after resume by default.<br /> <br /> (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)