Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix overflow in blk_ioctl_discard()<br /> <br /> There is no check for overflow of &amp;#39;start + len&amp;#39; in blk_ioctl_discard().<br /> Hung task occurs if submit an discard ioctl with the following param:<br /> start = 0x80000000000ff000, len = 0x8000000000fff000;<br /> Add the overflow validation now.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Check bloom filter map value size<br /> <br /> This patch adds a missing check to bloom filter creating, rejecting<br /> values above KMALLOC_MAX_SIZE. This brings the bloom map in line with<br /> many other map types.<br /> <br /> The lack of this protection can cause kernel crashes for value sizes<br /> that overflow int&amp;#39;s. Such a crash was caught by syzkaller. The next<br /> patch adds more guard-rails at a lower level.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Avoid memcpy field-spanning write WARNING<br /> <br /> When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver<br /> prints this WARNING message:<br /> <br /> memcpy: detected field-spanning write (size 128) of single field "bsg_reply_buf-&gt;reply_buf" at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1)<br /> WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr]<br /> <br /> The cause of the WARN is 128 bytes memcpy to the 1 byte size array "__u8<br /> replay_buf[1]" in the struct mpi3mr_bsg_in_reply_buf. The array is intended<br /> to be a flexible length array, so the WARN is a false positive.<br /> <br /> To suppress the WARN, remove the constant number &amp;#39;1&amp;#39; from the array<br /> declaration and clarify that it has flexible length. Also, adjust the<br /> memory allocation size to match the change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: guard against invalid STA ID on removal<br /> <br /> Guard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would<br /> result in out-of-bounds array accesses. This prevents issues should the<br /> driver get into a bad state during error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: read txq-&gt;read_ptr under lock<br /> <br /> If we read txq-&gt;read_ptr without lock, we can read the same<br /> value twice, then obtain the lock, and reclaim from there<br /> to two different places, but crucially reclaim the same<br /> entry twice, resulting in the WARN_ONCE() a little later.<br /> Fix that by reading txq-&gt;read_ptr under lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()<br /> <br /> lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the<br /> hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the<br /> hbalock to avoid potential deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> swiotlb: initialise restricted pool list_head when SWIOTLB_DYNAMIC=y<br /> <br /> Using restricted DMA pools (CONFIG_DMA_RESTRICTED_POOL=y) in conjunction<br /> with dynamic SWIOTLB (CONFIG_SWIOTLB_DYNAMIC=y) leads to the following<br /> crash when initialising the restricted pools at boot-time:<br /> <br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> | Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> | pc : rmem_swiotlb_device_init+0xfc/0x1ec<br /> | lr : rmem_swiotlb_device_init+0xf0/0x1ec<br /> | Call trace:<br /> | rmem_swiotlb_device_init+0xfc/0x1ec<br /> | of_reserved_mem_device_init_by_idx+0x18c/0x238<br /> | of_dma_configure_id+0x31c/0x33c<br /> | platform_dma_configure+0x34/0x80<br /> <br /> faddr2line reveals that the crash is in the list validation code:<br /> <br /> include/linux/list.h:83<br /> include/linux/rculist.h:79<br /> include/linux/rculist.h:106<br /> kernel/dma/swiotlb.c:306<br /> kernel/dma/swiotlb.c:1695<br /> <br /> because add_mem_pool() is trying to list_add_rcu() to a NULL<br /> &amp;#39;mem-&gt;pools&amp;#39;.<br /> <br /> Fix the crash by initialising the &amp;#39;mem-&gt;pools&amp;#39; list_head in<br /> rmem_swiotlb_device_init() before calling add_mem_pool().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries/iommu: LPAR panics during boot up with a frozen PE<br /> <br /> At the time of LPAR boot up, partition firmware provides Open Firmware<br /> property ibm,dma-window for the PE. This property is provided on the PCI<br /> bus the PE is attached to.<br /> <br /> There are execptions where the partition firmware might not provide this<br /> property for the PE at the time of LPAR boot up. One of the scenario is<br /> where the firmware has frozen the PE due to some error condition. This<br /> PE is frozen for 24 hours or unless the whole system is reinitialized.<br /> <br /> Within this time frame, if the LPAR is booted, the frozen PE will be<br /> presented to the LPAR but ibm,dma-window property could be missing.<br /> <br /> Today, under these circumstances, the LPAR oopses with NULL pointer<br /> dereference, when configuring the PCI bus the PE is attached to.<br /> <br /> BUG: Kernel NULL pointer dereference on read at 0x000000c8<br /> Faulting instruction address: 0xc0000000001024c0<br /> Oops: Kernel access of bad area, sig: 7 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in:<br /> Supported: Yes<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-150600.9-default #1<br /> Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_023) hv:phyp pSeries<br /> NIP: c0000000001024c0 LR: c0000000001024b0 CTR: c000000000102450<br /> REGS: c0000000037db5c0 TRAP: 0300 Not tainted (6.4.0-150600.9-default)<br /> MSR: 8000000002009033 CR: 28000822 XER: 00000000<br /> CFAR: c00000000010254c DAR: 00000000000000c8 DSISR: 00080000 IRQMASK: 0<br /> ...<br /> NIP [c0000000001024c0] pci_dma_bus_setup_pSeriesLP+0x70/0x2a0<br /> LR [c0000000001024b0] pci_dma_bus_setup_pSeriesLP+0x60/0x2a0<br /> Call Trace:<br /> pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 (unreliable)<br /> pcibios_setup_bus_self+0x1c0/0x370<br /> __of_scan_bus+0x2f8/0x330<br /> pcibios_scan_phb+0x280/0x3d0<br /> pcibios_init+0x88/0x12c<br /> do_one_initcall+0x60/0x320<br /> kernel_init_freeable+0x344/0x3e4<br /> kernel_init+0x34/0x1d0<br /> ret_from_kernel_user_thread+0x14/0x1c

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 /> ipv4: Fix uninit-value access in __ip_make_skb()<br /> <br /> KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb()<br /> tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a<br /> race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL<br /> while __ip_make_skb() is running, the function will access icmphdr in the<br /> skb even if it is not included. This causes the issue reported by KMSAN.<br /> <br /> Check FLOWI_FLAG_KNOWN_NH on fl4-&gt;flowi4_flags instead of testing HDRINCL<br /> on the socket.<br /> <br /> Also, fl4-&gt;fl4_icmp_type and fl4-&gt;fl4_icmp_code are not initialized. These<br /> are union in struct flowi4 and are implicitly initialized by<br /> flowi4_init_output(), but we should not rely on specific union layout.<br /> <br /> Initialize these explicitly in raw_sendmsg().<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481<br /> __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481<br /> ip_finish_skb include/net/ip.h:243 [inline]<br /> ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508<br /> raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654<br /> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x274/0x3c0 net/socket.c:745<br /> __sys_sendto+0x62c/0x7b0 net/socket.c:2191<br /> __do_sys_sendto net/socket.c:2203 [inline]<br /> __se_sys_sendto net/socket.c:2199 [inline]<br /> __x64_sys_sendto+0x130/0x200 net/socket.c:2199<br /> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:3804 [inline]<br /> slab_alloc_node mm/slub.c:3845 [inline]<br /> kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888<br /> kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577<br /> __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668<br /> alloc_skb include/linux/skbuff.h:1318 [inline]<br /> __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128<br /> ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365<br /> raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648<br /> inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x274/0x3c0 net/socket.c:745<br /> __sys_sendto+0x62c/0x7b0 net/socket.c:2191<br /> __do_sys_sendto net/socket.c:2203 [inline]<br /> __se_sys_sendto net/socket.c:2199 [inline]<br /> __x64_sys_sendto+0x130/0x200 net/socket.c:2199<br /> do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload<br /> <br /> The session resources are used by FW and driver when session is offloaded,<br /> once session is uploaded these resources are not used. The lock is not<br /> required as these fields won&amp;#39;t be used any longer. The offload and upload<br /> calls are sequential, hence lock is not required.<br /> <br /> This will suppress following BUG_ON():<br /> <br /> [ 449.843143] ------------[ cut here ]------------<br /> [ 449.848302] kernel BUG at mm/vmalloc.c:2727!<br /> [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1<br /> Rebooting.<br /> [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016<br /> [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]<br /> [ 449.882910] RIP: 0010:vunmap+0x2e/0x30<br /> [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41<br /> [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206<br /> [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005<br /> [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000<br /> [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf<br /> [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000<br /> [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0<br /> [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000<br /> [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0<br /> [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 449.993028] Call Trace:<br /> [ 449.995756] __iommu_dma_free+0x96/0x100<br /> [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]<br /> [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]<br /> [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]<br /> [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]<br /> [ 450.023103] process_one_work+0x1e8/0x3c0<br /> [ 450.027581] worker_thread+0x50/0x3b0<br /> [ 450.031669] ? rescuer_thread+0x370/0x370<br /> [ 450.036143] kthread+0x149/0x170<br /> [ 450.039744] ? set_kthread_struct+0x40/0x40<br /> [ 450.044411] ret_from_fork+0x22/0x30<br /> [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls<br /> [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler<br /> [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9381/1: kasan: clear stale stack poison<br /> <br /> We found below OOB crash:<br /> <br /> [ 33.452494] ==================================================================<br /> [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec<br /> [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0<br /> [ 33.455515]<br /> [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1<br /> [ 33.456880] Hardware name: Generic DT based system<br /> [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c<br /> [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c<br /> [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4<br /> [ 33.459863] print_report from kasan_report+0x9c/0x148<br /> [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0<br /> [ 33.461424] kasan_check_range from memset+0x20/0x3c<br /> [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec<br /> [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c<br /> [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354<br /> [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24<br /> [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4<br /> [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18<br /> [ 33.467397]<br /> [ 33.467644] The buggy address belongs to stack of task swapper/0/0<br /> [ 33.468493] and is located at offset 112 in frame:<br /> [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec<br /> [ 33.469917]<br /> [ 33.470165] This frame has 2 objects:<br /> [ 33.470696] [32, 76) &amp;#39;global_zone_diff&amp;#39;<br /> [ 33.470729] [112, 276) &amp;#39;global_node_diff&amp;#39;<br /> [ 33.471294]<br /> [ 33.472095] The buggy address belongs to the physical page:<br /> [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03<br /> [ 33.473944] flags: 0x1000(reserved|zone=0)<br /> [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001<br /> [ 33.475656] raw: 00000000<br /> [ 33.476050] page dumped because: kasan: bad access detected<br /> [ 33.476816]<br /> [ 33.477061] Memory state around the buggy address:<br /> [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00<br /> [ 33.479526] &gt;c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1<br /> [ 33.480415] ^<br /> [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3<br /> [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 33.482978] ==================================================================<br /> <br /> We find the root cause of this OOB is that arm does not clear stale stack<br /> poison in the case of cpuidle.<br /> <br /> This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.<br /> <br /> From cited commit [1] that explain the problem<br /> <br /> Functions which the compiler has instrumented for KASAN place poison on<br /> the stack shadow upon entry and remove this poison prior to returning.<br /> <br /> In the case of cpuidle, CPUs exit the kernel a number of levels deep in<br /> C code. Any instrumented functions on this critical path will leave<br /> portions of the stack shadow poisoned.<br /> <br /> If CPUs lose context and return to the kernel via a cold path, we<br /> restore a prior context saved in __cpu_suspend_enter are forgotten, and<br /> we never remove the poison they placed in the stack shadow area by<br /> functions calls between this and the actual exit of the kernel.<br /> <br /> Thus, (depending on stackframe layout) subsequent calls to instrumented<br /> functions may hit this stale poison, resulting in (spurious) KASAN<br /> splats to the console.<br /> <br /> To avoid this, clear any stale poison from the idle thread for a CPU<br /> prior to bringing a CPU online.<br /> <br /> From cited commit [2]<br /> <br /> Extend to check for CONFIG_KASAN_STACK<br /> <br /> [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison")<br /> [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")