Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix WQ_MEM_RECLAIM warning<br /> <br /> When sunrpc is used, if a reset triggered, our wq may lead the<br /> following trace:<br /> <br /> workqueue: WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker [rpcrdma]<br /> is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq:flush_work_handle<br /> [hns_roce_hw_v2]<br /> WARNING: CPU: 0 PID: 8250 at kernel/workqueue.c:2644 check_flush_dependency+0xe0/0x144<br /> Call trace:<br /> check_flush_dependency+0xe0/0x144<br /> start_flush_work.constprop.0+0x1d0/0x2f0<br /> __flush_work.isra.0+0x40/0xb0<br /> flush_work+0x14/0x30<br /> hns_roce_v2_destroy_qp+0xac/0x1e0 [hns_roce_hw_v2]<br /> ib_destroy_qp_user+0x9c/0x2b4<br /> rdma_destroy_qp+0x34/0xb0<br /> rpcrdma_ep_destroy+0x28/0xcc [rpcrdma]<br /> rpcrdma_ep_put+0x74/0xb4 [rpcrdma]<br /> rpcrdma_xprt_disconnect+0x1d8/0x260 [rpcrdma]<br /> xprt_rdma_connect_worker+0xc0/0x120 [rpcrdma]<br /> process_one_work+0x1cc/0x4d0<br /> worker_thread+0x154/0x414<br /> kthread+0x104/0x144<br /> ret_from_fork+0x10/0x18<br /> <br /> Since QP destruction frees memory, this wq should have the WQ_MEM_RECLAIM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP<br /> <br /> Yizhou Zhao reported that simply having one RAW socket on protocol<br /> IPPROTO_RAW (255) was dangerous.<br /> <br /> socket(AF_INET, SOCK_RAW, 255);<br /> <br /> A malicious incoming ICMP packet can set the protocol field to 255<br /> and match this socket, leading to FNHE cache changes.<br /> <br /> inner = IP(src="192.168.2.1", dst="8.8.8.8", proto=255)/Raw("TEST")<br /> pkt = IP(src="192.168.1.1", dst="192.168.2.1")/ICMP(type=3, code=4, nexthopmtu=576)/inner<br /> <br /> "man 7 raw" states:<br /> <br /> A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able<br /> to send any IP protocol that is specified in the passed header.<br /> Receiving of all IP protocols via IPPROTO_RAW is not possible<br /> using raw sockets.<br /> <br /> Make sure we drop these malicious packets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: hci: shdlc: Stop timers and work before freeing context<br /> <br /> llc_shdlc_deinit() purges SHDLC skb queues and frees the llc_shdlc<br /> structure while its timers and state machine work may still be active.<br /> <br /> Timer callbacks can schedule sm_work, and sm_work accesses SHDLC state<br /> and the skb queues. If teardown happens in parallel with a queued/running<br /> work item, it can lead to UAF and other shutdown races.<br /> <br /> Stop all SHDLC timers and cancel sm_work synchronously before purging the<br /> queues and freeing the context.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/P2PDMA: Fix p2pmem_alloc_mmap() warning condition<br /> <br /> Commit b7e282378773 has already changed the initial page refcount of<br /> p2pdma page from one to zero, however, in p2pmem_alloc_mmap() it uses<br /> "VM_WARN_ON_ONCE_PAGE(!page_ref_count(page))" to assert the initial page<br /> refcount should not be zero and the following will be reported when<br /> CONFIG_DEBUG_VM is enabled:<br /> <br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x380400000<br /> flags: 0x20000000002000(reserved|node=0|zone=4)<br /> raw: 0020000000002000 ff1100015e3ab440 0000000000000000 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: VM_WARN_ON_ONCE_PAGE(!page_ref_count(page))<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 5 PID: 449 at drivers/pci/p2pdma.c:240 p2pmem_alloc_mmap+0x83a/0xa60<br /> <br /> Fix by using "page_ref_count(page)" as the assertion condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: canaan: k230: Fix NULL pointer dereference when parsing devicetree<br /> <br /> When probing the k230 pinctrl driver, the kernel triggers a NULL pointer<br /> dereference. The crash trace showed:<br /> [ 0.732084] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000068<br /> [ 0.740737] ...<br /> [ 0.776296] epc : k230_pinctrl_probe+0x1be/0x4fc<br /> <br /> In k230_pinctrl_parse_functions(), we attempt to retrieve the device<br /> pointer via info-&gt;pctl_dev-&gt;dev, but info-&gt;pctl_dev is only initialized<br /> after k230_pinctrl_parse_dt() completes.<br /> <br /> At the time of DT parsing, info-&gt;pctl_dev is still NULL, leading to<br /> the invalid dereference of info-&gt;pctl_dev-&gt;dev.<br /> <br /> Use the already available device pointer from platform_device<br /> instead of accessing through uninitialized pctl_dev.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: rt9455: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: do WoW offloads only on primary link<br /> <br /> In case of multi-link connection, WCN7850 firmware crashes due to WoW<br /> offloads enabled on both primary and secondary links.<br /> <br /> Change to do it only on primary link to fix it.<br /> <br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/pf: Fix sysfs initialization<br /> <br /> In case of devm_add_action_or_reset() failure the provided cleanup<br /> action will be run immediately on the not yet initialized kobject.<br /> This may lead to errors like:<br /> <br /> [ ] kobject: &amp;#39;(null)&amp;#39; (ff110001393608e0): is not initialized, yet kobject_put() is being called.<br /> [ ] WARNING: lib/kobject.c:734 at kobject_put+0xd9/0x250, CPU#0: kworker/0:0/9<br /> [ ] RIP: 0010:kobject_put+0xdf/0x250<br /> [ ] Call Trace:<br /> [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe]<br /> [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe]<br /> [ ] xe_sriov_init_late+0x5f/0x2c0 [xe]<br /> [ ] xe_device_probe+0x5f2/0xc20 [xe]<br /> [ ] xe_pci_probe+0x396/0x610 [xe]<br /> [ ] local_pci_probe+0x47/0xb0<br /> <br /> [ ] refcount_t: underflow; use-after-free.<br /> [ ] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x68/0xb0, CPU#0: kworker/0:0/9<br /> [ ] RIP: 0010:refcount_warn_saturate+0x68/0xb0<br /> [ ] Call Trace:<br /> [ ] kobject_put+0x174/0x250<br /> [ ] xe_sriov_pf_sysfs_init+0x21/0x100 [xe]<br /> [ ] xe_sriov_pf_init_late+0x87/0x2b0 [xe]<br /> [ ] xe_sriov_init_late+0x5f/0x2c0 [xe]<br /> [ ] xe_device_probe+0x5f2/0xc20 [xe]<br /> [ ] xe_pci_probe+0x396/0x610 [xe]<br /> [ ] local_pci_probe+0x47/0xb0<br /> <br /> Fix that by calling kobject_init() and kobject_add() separately<br /> and register cleanup action after the kobject is initialized.<br /> <br /> Also make this cleanup registration a part of the create helper to<br /> fix another mistake, as in the loop we were wrongly passing parent<br /> kobject while registering cleanup action, and this resulted in some<br /> undetected leaks.<br /> <br /> (cherry picked from commit 98b16727f07e26a5d4de84d88805ce7ffcfdd324)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix out-of-bounds stream encoder index v3<br /> <br /> eng_id can be negative and that stream_enc_regs[]<br /> can be indexed out of bounds.<br /> <br /> eng_id is used directly as an index into stream_enc_regs[], which has<br /> only 5 entries. When eng_id is 5 (ENGINE_ID_DIGF) or negative, this can<br /> access memory past the end of the array.<br /> <br /> Add a bounds check using ARRAY_SIZE() before using eng_id as an index.<br /> The unsigned cast also rejects negative values.<br /> <br /> This avoids out-of-bounds access.<br /> <br /> Fixes the below smatch error:<br /> dcn*_resource.c: stream_encoder_create() may index<br /> stream_enc_regs[eng_id] out of bounds (size 5).<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351_resource.c<br /> 1246 static struct stream_encoder *dcn35_stream_encoder_create(<br /> 1247 enum engine_id eng_id,<br /> 1248 struct dc_context *ctx)<br /> 1249 {<br /> <br /> ...<br /> <br /> 1255<br /> 1256 /* Mapping of VPG, AFMT, DME register blocks to DIO block instance */<br /> 1257 if (eng_id

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: fsl_xcvr: Revert fix missing lock in fsl_xcvr_mode_put()<br /> <br /> This reverts commit f51424872760 ("ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()").<br /> <br /> The original patch attempted to acquire the card-&gt;controls_rwsem lock in<br /> fsl_xcvr_mode_put(). However, this function is called from the upper ALSA<br /> core function snd_ctl_elem_write(), which already holds the write lock on<br /> controls_rwsem for the whole put operation. So there is no need to simply<br /> hold the lock for fsl_xcvr_activate_ctl() again.<br /> <br /> Acquiring the read lock while holding the write lock in the same thread<br /> results in a deadlock and a hung task, as reported by Alexander Stein.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: wpcm-fiu: Fix potential NULL pointer dereference in wpcm_fiu_probe()<br /> <br /> platform_get_resource_byname() can return NULL, which would cause a crash<br /> when passed the pointer to resource_size().<br /> <br /> Move the fiu-&gt;memory_size assignment after the error check for<br /> devm_ioremap_resource() to prevent the potential NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix out-of-bound access in fib6_add_rt2node().<br /> <br /> syzbot reported out-of-bound read in fib6_add_rt2node(). [0]<br /> <br /> When IPv6 route is created with RTA_NH_ID, struct fib6_info<br /> does not have the trailing struct fib6_nh.<br /> <br /> The cited commit started to check !iter-&gt;fib6_nh-&gt;fib_nh_gw_family<br /> to ensure that rt6_qualify_for_ecmp() will return false for iter.<br /> <br /> If iter-&gt;nh is not NULL, rt6_qualify_for_ecmp() returns false anyway.<br /> <br /> Let&amp;#39;s check iter-&gt;nh before reading iter-&gt;fib6_nh and avoid OOB read.<br /> <br /> [0]:<br /> BUG: KASAN: slab-out-of-bounds in fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142<br /> Read of size 1 at addr ffff8880384ba6de by task syz.0.18/5500<br /> <br /> CPU: 0 UID: 0 PID: 5500 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xba/0x230 mm/kasan/report.c:482<br /> kasan_report+0x117/0x150 mm/kasan/report.c:595<br /> fib6_add_rt2node+0x349c/0x3500 net/ipv6/ip6_fib.c:1142<br /> fib6_add_rt2node_nh net/ipv6/ip6_fib.c:1363 [inline]<br /> fib6_add+0x910/0x18c0 net/ipv6/ip6_fib.c:1531<br /> __ip6_ins_rt net/ipv6/route.c:1351 [inline]<br /> ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3957<br /> inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660<br /> rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958<br /> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592<br /> ___sys_sendmsg+0x2a5/0x360 net/socket.c:2646<br /> __sys_sendmsg net/socket.c:2678 [inline]<br /> __do_sys_sendmsg net/socket.c:2683 [inline]<br /> __se_sys_sendmsg net/socket.c:2681 [inline]<br /> __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f9316b9aeb9<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffd8809b678 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f9316e15fa0 RCX: 00007f9316b9aeb9<br /> RDX: 0000000000000000 RSI: 0000200000004380 RDI: 0000000000000003<br /> RBP: 00007f9316c08c1f R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f9316e15fac R14: 00007f9316e15fa0 R15: 00007f9316e15fa0<br /> <br /> <br /> Allocated by task 5499:<br /> kasan_save_stack mm/kasan/common.c:57 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __do_kmalloc_node mm/slub.c:5657 [inline]<br /> __kmalloc_noprof+0x40c/0x7e0 mm/slub.c:5669<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> fib6_info_alloc+0x30/0xf0 net/ipv6/ip6_fib.c:155<br /> ip6_route_info_create+0x142/0x860 net/ipv6/route.c:3820<br /> ip6_route_add+0x49/0x1b0 net/ipv6/route.c:3949<br /> inet6_rtm_newroute+0x268/0x19e0 net/ipv6/route.c:5660<br /> rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958<br /> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592<br /> ___sys_s<br /> ---truncated---