Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock()<br /> <br /> Since the user can control the arguments of the ioctl() from the user<br /> space, under special arguments that may result in a divide-by-zero bug<br /> in:<br /> drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info-&gt;var.pixclock) / hmul);<br /> with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0.<br /> and then in:<br /> drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par-&gt;dac, 0, 1000000000 / pixclock);<br /> we&amp;#39;ll get a division-by-zero.<br /> <br /> The following log can reveal it:<br /> <br /> divide error: 0000 [#1] PREEMPT SMP KASAN PTI<br /> RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [inline]<br /> RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784<br /> Call Trace:<br /> fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034<br /> do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110<br /> fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189<br /> <br /> Fix this by checking the argument of ark_set_pixclock() first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: vt8623fb: Check the size of screen before memset_io()<br /> <br /> In the function vt8623fb_set_par(), the value of &amp;#39;screen_size&amp;#39; is<br /> calculated by the user input. If the user provides the improper value,<br /> the value of &amp;#39;screen_size&amp;#39; may larger than &amp;#39;info-&gt;screen_size&amp;#39;, which<br /> may cause the following bug:<br /> <br /> [ 583.339036] BUG: unable to handle page fault for address: ffffc90005000000<br /> [ 583.339049] #PF: supervisor write access in kernel mode<br /> [ 583.339052] #PF: error_code(0x0002) - not-present page<br /> [ 583.339074] RIP: 0010:memset_orig+0x33/0xb0<br /> [ 583.339110] Call Trace:<br /> [ 583.339118] vt8623fb_set_par+0x11cd/0x21e0<br /> [ 583.339146] fb_set_var+0x604/0xeb0<br /> [ 583.339181] do_fb_ioctl+0x234/0x670<br /> [ 583.339209] fb_ioctl+0xdd/0x130<br /> <br /> Fix the this by checking the value of &amp;#39;screen_size&amp;#39; before memset_io().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/core: Do not requeue task on CPU excluded from cpus_mask<br /> <br /> The following warning was triggered on a large machine early in boot on<br /> a distribution kernel but the same problem should also affect mainline.<br /> <br /> WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440<br /> Call Trace:<br /> <br /> rescuer_thread+0x1f6/0x360<br /> kthread+0x156/0x180<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p-&gt;on_cpu")<br /> optimises ttwu by queueing a task that is descheduling on the wakelist,<br /> but does not check if the task descheduling is still allowed to run on that CPU.<br /> <br /> In this warning, the problematic task is a workqueue rescue thread which<br /> checks if the rescue is for a per-cpu workqueue and running on the wrong CPU.<br /> While this is early in boot and it should be possible to create workers,<br /> the rescue thread may still used if the MAYDAY_INITIAL_TIMEOUT is reached<br /> or MAYDAY_INTERVAL and on a sufficiently large machine, the rescue<br /> thread is being used frequently.<br /> <br /> Tracing confirmed that the task should have migrated properly using the<br /> stopper thread to handle the migration. However, a parallel wakeup from udev<br /> running on another CPU that does not share CPU cache observes p-&gt;on_cpu and<br /> uses task_cpu(p), queues the task on the old CPU and triggers the warning.<br /> <br /> Check that the wakee task that is descheduling is still allowed to run<br /> on its current CPU and if not, wait for the descheduling to complete<br /> and select an allowed CPU.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: arkfb: Check the size of screen before memset_io()<br /> <br /> In the function arkfb_set_par(), the value of &amp;#39;screen_size&amp;#39; is<br /> calculated by the user input. If the user provides the improper value,<br /> the value of &amp;#39;screen_size&amp;#39; may larger than &amp;#39;info-&gt;screen_size&amp;#39;, which<br /> may cause the following bug:<br /> <br /> [ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000<br /> [ 659.399077] #PF: supervisor write access in kernel mode<br /> [ 659.399079] #PF: error_code(0x0002) - not-present page<br /> [ 659.399094] RIP: 0010:memset_orig+0x33/0xb0<br /> [ 659.399116] Call Trace:<br /> [ 659.399122] arkfb_set_par+0x143f/0x24c0<br /> [ 659.399130] fb_set_var+0x604/0xeb0<br /> [ 659.399161] do_fb_ioctl+0x234/0x670<br /> [ 659.399189] fb_ioctl+0xdd/0x130<br /> <br /> Fix the this by checking the value of &amp;#39;screen_size&amp;#39; before memset_io().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts<br /> <br /> Ensure SRB is returned during I/O timeout error escalation. If that is not<br /> possible fail the escalation path.<br /> <br /> Following crash stack was seen:<br /> <br /> BUG: unable to handle kernel paging request at 0000002f56aa90f8<br /> IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]<br /> Call Trace:<br /> ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]<br /> ? qla2x00_start_sp+0x116/0x1170 [qla2xxx]<br /> ? dma_pool_alloc+0x1d6/0x210<br /> ? mempool_alloc+0x54/0x130<br /> ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]<br /> ? qla_do_work+0x2d/0x40 [qla2xxx]<br /> ? process_one_work+0x14c/0x390

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: s3fb: Check the size of screen before memset_io()<br /> <br /> In the function s3fb_set_par(), the value of &amp;#39;screen_size&amp;#39; is<br /> calculated by the user input. If the user provides the improper value,<br /> the value of &amp;#39;screen_size&amp;#39; may larger than &amp;#39;info-&gt;screen_size&amp;#39;, which<br /> may cause the following bug:<br /> <br /> [ 54.083733] BUG: unable to handle page fault for address: ffffc90003000000<br /> [ 54.083742] #PF: supervisor write access in kernel mode<br /> [ 54.083744] #PF: error_code(0x0002) - not-present page<br /> [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0<br /> [ 54.083782] Call Trace:<br /> [ 54.083788] s3fb_set_par+0x1ec6/0x4040<br /> [ 54.083806] fb_set_var+0x604/0xeb0<br /> [ 54.083836] do_fb_ioctl+0x234/0x670<br /> <br /> Fix the this by checking the value of &amp;#39;screen_size&amp;#39; before memset_io().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kprobes: Update kcb status flag after singlestepping<br /> <br /> Fix kprobes to update kcb (kprobes control block) status flag to<br /> KPROBE_HIT_SSDONE even if the kp-&gt;post_handler is not set.<br /> <br /> This bug may cause a kernel panic if another INT3 user runs right<br /> after kprobes because kprobe_int3_handler() misunderstands the<br /> INT3 is kprobe&amp;#39;s single stepping INT3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/csd_lock: Change csdlock_debug from early_param to __setup<br /> <br /> The csdlock_debug kernel-boot parameter is parsed by the<br /> early_param() function csdlock_debug(). If set, csdlock_debug()<br /> invokes static_branch_enable() to enable csd_lock_wait feature, which<br /> triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and<br /> CONFIG_SPARSEMEM_VMEMMAP=n.<br /> <br /> With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in<br /> static_key_enable() and returns NULL, resulting in a NULL dereference<br /> because mem_section is initialized only later in sparse_init().<br /> <br /> This is also a problem for powerpc because early_param() functions<br /> are invoked earlier than jump_label_init(), also resulting in<br /> static_key_enable() failures. These failures cause the warning "static<br /> key &amp;#39;xxx&amp;#39; used before call to jump_label_init()".<br /> <br /> Thus, early_param is too early for csd_lock_wait to run<br /> static_branch_enable(), so changes it to __setup to fix these.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info-&gt;max_extent_size<br /> <br /> On zoned filesystem, data write out is limited by max_zone_append_size,<br /> and a large ordered extent is split according the size of a bio. OTOH,<br /> the number of extents to be written is calculated using<br /> BTRFS_MAX_EXTENT_SIZE, and that estimated number is used to reserve the<br /> metadata bytes to update and/or create the metadata items.<br /> <br /> The metadata reservation is done at e.g, btrfs_buffered_write() and then<br /> released according to the estimation changes. Thus, if the number of extent<br /> increases massively, the reserved metadata can run out.<br /> <br /> The increase of the number of extents easily occurs on zoned filesystem<br /> if BTRFS_MAX_EXTENT_SIZE &gt; max_zone_append_size. And, it causes the<br /> following warning on a small RAM environment with disabling metadata<br /> over-commit (in the following patch).<br /> <br /> [75721.498492] ------------[ cut here ]------------<br /> [75721.505624] BTRFS: block rsv 1 returned -28<br /> [75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs]<br /> [75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: loaded Tainted: G W 5.18.0-rc2-BTRFS-ZNS+ #109<br /> [75721.597200] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021<br /> [75721.607310] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]<br /> [75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs]<br /> [75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286<br /> [75721.654126] RAX: 0000000000000000 RBX: 0000000000004000 RCX: 0000000000000000<br /> [75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e<br /> [75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7<br /> [75721.682493] R10: ffffed13f1a3f8d8 R11: 0000000000000001 R12: ffff88980a3c0e28<br /> [75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a<br /> [75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000<br /> [75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0<br /> [75721.730499] Call Trace:<br /> [75721.735166] <br /> [75721.739886] btrfs_alloc_tree_block+0x1e1/0x1100 [btrfs]<br /> [75721.747545] ? btrfs_alloc_logged_file_extent+0x550/0x550 [btrfs]<br /> [75721.756145] ? btrfs_get_32+0xea/0x2d0 [btrfs]<br /> [75721.762852] ? btrfs_get_32+0xea/0x2d0 [btrfs]<br /> [75721.769520] ? push_leaf_left+0x420/0x620 [btrfs]<br /> [75721.776431] ? memcpy+0x4e/0x60<br /> [75721.781931] split_leaf+0x433/0x12d0 [btrfs]<br /> [75721.788392] ? btrfs_get_token_32+0x580/0x580 [btrfs]<br /> [75721.795636] ? push_for_double_split.isra.0+0x420/0x420 [btrfs]<br /> [75721.803759] ? leaf_space_used+0x15d/0x1a0 [btrfs]<br /> [75721.811156] btrfs_search_slot+0x1bc3/0x2790 [btrfs]<br /> [75721.818300] ? lock_downgrade+0x7c0/0x7c0<br /> [75721.824411] ? free_extent_buffer.part.0+0x107/0x200 [btrfs]<br /> [75721.832456] ? split_leaf+0x12d0/0x12d0 [btrfs]<br /> [75721.839149] ? free_extent_buffer.part.0+0x14f/0x200 [btrfs]<br /> [75721.846945] ? free_extent_buffer+0x13/0x20 [btrfs]<br /> [75721.853960] ? btrfs_release_path+0x4b/0x190 [btrfs]<br /> [75721.861429] btrfs_csum_file_blocks+0x85c/0x1500 [btrfs]<br /> [75721.869313] ? rcu_read_lock_sched_held+0x16/0x80<br /> [75721.876085] ? lock_release+0x552/0xf80<br /> [75721.881957] ? btrfs_del_csums+0x8c0/0x8c0 [btrfs]<br /> [75721.888886] ? __kasan_check_write+0x14/0x20<br /> [75721.895152] ? do_raw_read_unlock+0x44/0x80<br /> [75721.901323] ? _raw_write_lock_irq+0x60/0x80<br /> [75721.907983] ? btrfs_global_root+0xb9/0xe0 [btrfs]<br /> [75721.915166] ? btrfs_csum_root+0x12b/0x180 [btrfs]<br /> [75721.921918] ? btrfs_get_global_root+0x820/0x820 [btrfs]<br /> [75721.929166] ? _raw_write_unlock+0x23/0x40<br /> [75721.935116] ? unpin_extent_cache+0x1e3/0x390 [btrfs]<br /> [75721.942041] btrfs_finish_ordered_io.isra.0+0xa0c/0x1dc0 [btrfs]<br /> [75721.949906] ? try_to_wake_up+0x30/0x14a0<br /> [75721.955700] ? btrfs_unlink_subvol+0xda0/0xda0 [btrfs]<br /> [75721.962661] ? rcu<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: ensure pages are unlocked on cow_file_range() failure<br /> <br /> There is a hung_task report on zoned btrfs like below.<br /> <br /> https://github.com/naota/linux/issues/59<br /> <br /> [726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds.<br /> [726.329839] Not tainted 5.16.0-rc1+ #1<br /> [726.330484] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000<br /> [726.331608] Call Trace:<br /> [726.331611] <br /> [726.331614] __schedule+0x2e5/0x9d0<br /> [726.331622] schedule+0x58/0xd0<br /> [726.331626] io_schedule+0x3f/0x70<br /> [726.331629] __folio_lock+0x125/0x200<br /> [726.331634] ? find_get_entries+0x1bc/0x240<br /> [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40<br /> [726.331642] truncate_inode_pages_range+0x5b2/0x770<br /> [726.331649] truncate_inode_pages_final+0x44/0x50<br /> [726.331653] btrfs_evict_inode+0x67/0x480<br /> [726.331658] evict+0xd0/0x180<br /> [726.331661] iput+0x13f/0x200<br /> [726.331664] do_unlinkat+0x1c0/0x2b0<br /> [726.331668] __x64_sys_unlink+0x23/0x30<br /> [726.331670] do_syscall_64+0x3b/0xc0<br /> [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [726.331677] RIP: 0033:0x7fb9490a171b<br /> [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057<br /> [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b<br /> [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300<br /> [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000<br /> [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000<br /> [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260<br /> [726.331693] <br /> <br /> While we debug the issue, we found running fstests generic/551 on 5GB<br /> non-zoned null_blk device in the emulated zoned mode also had a<br /> similar hung issue.<br /> <br /> Also, we can reproduce the same symptom with an error injected<br /> cow_file_range() setup.<br /> <br /> The hang occurs when cow_file_range() fails in the middle of<br /> allocation. cow_file_range() called from do_allocation_zoned() can<br /> split the give region ([start, end]) for allocation depending on<br /> current block group usages. When btrfs can allocate bytes for one part<br /> of the split regions but fails for the other region (e.g. because of<br /> -ENOSPC), we return the error leaving the pages in the succeeded regions<br /> locked. Technically, this occurs only when @unlock == 0. Otherwise, we<br /> unlock the pages in an allocated region after creating an ordered<br /> extent.<br /> <br /> Considering the callers of cow_file_range(unlock=0) won&amp;#39;t write out<br /> the pages, we can unlock the pages on error exit from<br /> cow_file_range(). So, we can ensure all the pages except @locked_page<br /> are unlocked on error case.<br /> <br /> In summary, cow_file_range now behaves like this:<br /> <br /> - page_started == 1 (return value)<br /> - All the pages are unlocked. IO is started.<br /> - unlock == 1<br /> - All the pages except @locked_page are unlocked in any case<br /> - unlock == 0<br /> - On success, all the pages are locked for writing out them<br /> - On failure, all the pages except @locked_page are unlocked

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)<br /> <br /> KASAN reports:<br /> <br /> [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)<br /> [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0<br /> [ 4.683454][ T0]<br /> [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1<br /> [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016<br /> [ 4.703196][ T0] Call Trace:<br /> [ 4.706334][ T0] <br /> [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)<br /> <br /> after converting the type of the first argument (@nr, bit number)<br /> of arch_test_bit() from `long` to `unsigned long`[0].<br /> <br /> Under certain conditions (for example, when ACPI NUMA is disabled<br /> via command line), pxm_to_node() can return %NUMA_NO_NODE (-1).<br /> It is valid &amp;#39;magic&amp;#39; number of NUMA node, but not valid bit number<br /> to use in bitops.<br /> node_online() eventually descends to test_bit() without checking<br /> for the input, assuming it&amp;#39;s on caller side (which might be good<br /> for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads<br /> to an insane array index when calculating bit position in memory.<br /> <br /> For now, add an explicit check for @node being not %NUMA_NO_NODE<br /> before calling test_bit(). The actual logics didn&amp;#39;t change here<br /> at all.<br /> <br /> [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spmi: trace: fix stack-out-of-bound access in SPMI tracing functions<br /> <br /> trace_spmi_write_begin() and trace_spmi_read_end() both call<br /> memcpy() with a length of "len + 1". This leads to one extra<br /> byte being read beyond the end of the specified buffer. Fix<br /> this out-of-bound memory access by using a length of "len"<br /> instead.<br /> <br /> Here is a KASAN log showing the issue:<br /> <br /> BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234<br /> Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314<br /> ...<br /> Call trace:<br /> dump_backtrace+0x0/0x3e8<br /> show_stack+0x2c/0x3c<br /> dump_stack_lvl+0xdc/0x11c<br /> print_address_description+0x74/0x384<br /> kasan_report+0x188/0x268<br /> kasan_check_range+0x270/0x2b0<br /> memcpy+0x90/0xe8<br /> trace_event_raw_event_spmi_read_end+0x1d0/0x234<br /> spmi_read_cmd+0x294/0x3ac<br /> spmi_ext_register_readl+0x84/0x9c<br /> regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]<br /> _regmap_raw_read+0x40c/0x754<br /> regmap_raw_read+0x3a0/0x514<br /> regmap_bulk_read+0x418/0x494<br /> adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]<br /> ...<br /> __arm64_sys_read+0x4c/0x60<br /> invoke_syscall+0x80/0x218<br /> el0_svc_common+0xec/0x1c8<br /> ...<br /> <br /> addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:<br /> adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]<br /> <br /> this frame has 1 object:<br /> [32, 33) &amp;#39;status&amp;#39;<br /> <br /> Memory state around the buggy address:<br /> ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1<br /> ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00<br /> ^<br /> ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00<br /> ==================================================================