Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: safexcel - Cleanup ring IRQ workqueues on load failure<br /> <br /> A failure loading the safexcel driver results in the following warning<br /> on boot, because the IRQ affinity has not been correctly cleaned up.<br /> Ensure we clean up the affinity and workqueues on a failure to load the<br /> driver.<br /> <br /> crypto-safexcel: probe of f2800000.crypto failed with error -2<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340<br /> Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4<br /> CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G W 6.1.6-00002-g9d4898824677 #3<br /> Hardware name: MikroTik RB5009 (DT)<br /> pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : free_irq+0x300/0x340<br /> lr : free_irq+0x2e0/0x340<br /> sp : ffff800008fa3890<br /> x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000<br /> x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50<br /> x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80<br /> x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5e<br /> x14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040<br /> x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370<br /> x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18<br /> x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188<br /> x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0<br /> Call trace:<br /> free_irq+0x300/0x340<br /> devm_irq_release+0x14/0x20<br /> devres_release_all+0xa0/0x100<br /> device_unbind_cleanup+0x14/0x60<br /> really_probe+0x198/0x2d4<br /> __driver_probe_device+0x74/0xdc<br /> driver_probe_device+0x3c/0x110<br /> __driver_attach+0x8c/0x190<br /> bus_for_each_dev+0x6c/0xc0<br /> driver_attach+0x20/0x30<br /> bus_add_driver+0x148/0x1fc<br /> driver_register+0x74/0x120<br /> __platform_driver_register+0x24/0x30<br /> safexcel_init+0x48/0x1000 [crypto_safexcel]<br /> do_one_initcall+0x4c/0x1b0<br /> do_init_module+0x44/0x1cc<br /> load_module+0x1724/0x1be4<br /> __do_sys_finit_module+0xbc/0x110<br /> __arm64_sys_finit_module+0x1c/0x24<br /> invoke_syscall+0x44/0x110<br /> el0_svc_common.constprop.0+0xc0/0xe0<br /> do_el0_svc+0x20/0x80<br /> el0_svc+0x14/0x4c<br /> el0t_64_sync_handler+0xb0/0xb4<br /> el0t_64_sync+0x148/0x14c<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/jfs: prevent double-free in dbUnmount() after failed jfs_remount()<br /> <br /> Syzkaller reported the following issue:<br /> ==================================================================<br /> BUG: KASAN: double-free in slab_free mm/slub.c:3787 [inline]<br /> BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3800<br /> Free of addr ffff888086408000 by task syz-executor.4/12750<br /> [...]<br /> Call Trace:<br /> <br /> [...]<br /> kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:482<br /> ____kasan_slab_free+0xfb/0x120<br /> kasan_slab_free include/linux/kasan.h:177 [inline]<br /> slab_free_hook mm/slub.c:1781 [inline]<br /> slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807<br /> slab_free mm/slub.c:3787 [inline]<br /> __kmem_cache_free+0x71/0x110 mm/slub.c:3800<br /> dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264<br /> jfs_umount+0x248/0x3b0 fs/jfs/jfs_umount.c:87<br /> jfs_put_super+0x86/0x190 fs/jfs/super.c:194<br /> generic_shutdown_super+0x130/0x310 fs/super.c:492<br /> kill_block_super+0x79/0xd0 fs/super.c:1386<br /> deactivate_locked_super+0xa7/0xf0 fs/super.c:332<br /> cleanup_mnt+0x494/0x520 fs/namespace.c:1291<br /> task_work_run+0x243/0x300 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop+0x124/0x150 kernel/entry/common.c:171<br /> exit_to_user_mode_prepare+0xb2/0x140 kernel/entry/common.c:203<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]<br /> syscall_exit_to_user_mode+0x26/0x60 kernel/entry/common.c:296<br /> do_syscall_64+0x49/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> <br /> Allocated by task 13352:<br /> kasan_save_stack mm/kasan/common.c:45 [inline]<br /> kasan_set_track+0x3d/0x60 mm/kasan/common.c:52<br /> ____kasan_kmalloc mm/kasan/common.c:371 [inline]<br /> __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380<br /> kmalloc include/linux/slab.h:580 [inline]<br /> dbMount+0x54/0x980 fs/jfs/jfs_dmap.c:164<br /> jfs_mount+0x1dd/0x830 fs/jfs/jfs_mount.c:121<br /> jfs_fill_super+0x590/0xc50 fs/jfs/super.c:556<br /> mount_bdev+0x26c/0x3a0 fs/super.c:1359<br /> legacy_get_tree+0xea/0x180 fs/fs_context.c:610<br /> vfs_get_tree+0x88/0x270 fs/super.c:1489<br /> do_new_mount+0x289/0xad0 fs/namespace.c:3145<br /> do_mount fs/namespace.c:3488 [inline]<br /> __do_sys_mount fs/namespace.c:3697 [inline]<br /> __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Freed by task 13352:<br /> kasan_save_stack mm/kasan/common.c:45 [inline]<br /> kasan_set_track+0x3d/0x60 mm/kasan/common.c:52<br /> kasan_save_free_info+0x27/0x40 mm/kasan/generic.c:518<br /> ____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236<br /> kasan_slab_free include/linux/kasan.h:177 [inline]<br /> slab_free_hook mm/slub.c:1781 [inline]<br /> slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807<br /> slab_free mm/slub.c:3787 [inline]<br /> __kmem_cache_free+0x71/0x110 mm/slub.c:3800<br /> dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264<br /> jfs_mount_rw+0x545/0x740 fs/jfs/jfs_mount.c:247<br /> jfs_remount+0x3db/0x710 fs/jfs/super.c:454<br /> reconfigure_super+0x3bc/0x7b0 fs/super.c:935<br /> vfs_fsconfig_locked fs/fsopen.c:254 [inline]<br /> __do_sys_fsconfig fs/fsopen.c:439 [inline]<br /> __se_sys_fsconfig+0xad5/0x1060 fs/fsopen.c:314<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> JFS_SBI(ipbmap-&gt;i_sb)-&gt;bmap wasn&amp;#39;t set to NULL after kfree() in<br /> dbUnmount().<br /> <br /> Syzkaller uses faultinject to reproduce this KASAN double-free<br /> warning. The issue is triggered if either diMount() or dbMount() fail<br /> in jfs_remount(), since diUnmount() or dbUnmount() already happened in<br /> such a case - they will do double-free on next execution: jfs_umount<br /> or jfs_remount.<br /> <br /> Tested on both upstream and jfs-next by syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: drop peer group ids under namespace lock<br /> <br /> When cleaning up peer group ids in the failure path we need to make sure<br /> to hold on to the namespace lock. Otherwise another thread might just<br /> turn the mount from a shared into a non-shared mount concurrently.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Add validation for lmac type<br /> <br /> Upon physical link change, firmware reports to the kernel about the<br /> change along with the details like speed, lmac_type_id, etc.<br /> Kernel derives lmac_type based on lmac_type_id received from firmware.<br /> <br /> In a few scenarios, firmware returns an invalid lmac_type_id, which<br /> is resulting in below kernel panic. This patch adds the missing<br /> validation of the lmac_type_id field.<br /> <br /> Internal error: Oops: 96000005 [#1] PREEMPT SMP<br /> [ 35.321595] Modules linked in:<br /> [ 35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted<br /> 5.4.210-g2e3169d8e1bc-dirty #17<br /> [ 35.337014] Hardware name: Marvell CN103XX board (DT)<br /> [ 35.344297] Workqueue: events work_for_cpu_fn<br /> [ 35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO)<br /> [ 35.360267] pc : strncpy+0x10/0x30<br /> [ 35.366595] lr : cgx_link_change_handler+0x90/0x180

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs/hfsplus: avoid WARN_ON() for sanity check, use proper error handling<br /> <br /> Commit 55d1cbbbb29e ("hfs/hfsplus: use WARN_ON for sanity check") fixed<br /> a build warning by turning a comment into a WARN_ON(), but it turns out<br /> that syzbot then complains because it can trigger said warning with a<br /> corrupted hfs image.<br /> <br /> The warning actually does warn about a bad situation, but we are much<br /> better off just handling it as the error it is. So rather than warn<br /> about us doing bad things, stop doing the bad things and return -EIO.<br /> <br /> While at it, also fix a memory leak that was introduced by an earlier<br /> fix for a similar syzbot warning situation, and add a check for one case<br /> that historically wasn&amp;#39;t handled at all (ie neither comment nor<br /> subsequent WARN_ON).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: rockchip: Fix refcount leak in rockchip_pinctrl_parse_groups<br /> <br /> of_find_node_by_phandle() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: Fix memory leak in error path of kcm_sendmsg()<br /> <br /> syzbot reported a memory leak like below:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810b088c00 (size 240):<br /> comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s)<br /> hex dump (first 32 bytes):<br /> 00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634<br /> [] alloc_skb include/linux/skbuff.h:1289 [inline]<br /> [] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815<br /> [] sock_sendmsg_nosec net/socket.c:725 [inline]<br /> [] sock_sendmsg+0x56/0xb0 net/socket.c:748<br /> [] ____sys_sendmsg+0x365/0x470 net/socket.c:2494<br /> [] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548<br /> [] __sys_sendmsg+0xa6/0x120 net/socket.c:2577<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> In kcm_sendmsg(), kcm_tx_msg(head)-&gt;last_skb is used as a cursor to append<br /> newly allocated skbs to &amp;#39;head&amp;#39;. If some bytes are copied, an error occurred,<br /> and jumped to out_error label, &amp;#39;last_skb&amp;#39; is left unmodified. A later<br /> kcm_sendmsg() will use an obsoleted &amp;#39;last_skb&amp;#39; reference, corrupting the<br /> &amp;#39;head&amp;#39; frag_list and causing the leak.<br /> <br /> This patch fixes this issue by properly updating the last allocated skb in<br /> &amp;#39;last_skb&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: dump vmalloc memory info safely<br /> <br /> Currently, for double invoke call_rcu(), will dump rcu_head objects memory<br /> info, if the objects is not allocated from the slab allocator, the<br /> vmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need to<br /> be held, since the call_rcu() can be invoked in interrupt context,<br /> therefore, there is a possibility of spinlock deadlock scenarios.<br /> <br /> And in Preempt-RT kernel, the rcutorture test also trigger the following<br /> lockdep warning:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 1, expected: 1<br /> 3 locks held by swapper/0/1:<br /> #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0<br /> #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370<br /> #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70<br /> irq event stamp: 565512<br /> hardirqs last enabled at (565511): [] __call_rcu_common+0x218/0x940<br /> hardirqs last disabled at (565512): [] rcu_torture_init+0x20b2/0x2370<br /> softirqs last enabled at (399112): [] __local_bh_enable_ip+0x126/0x170<br /> softirqs last disabled at (399106): [] inet_register_protosw+0x9/0x1d0<br /> Preemption disabled at:<br /> [] rcu_torture_init+0x1f13/0x2370<br /> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x68/0xb0<br /> dump_stack+0x14/0x20<br /> __might_resched+0x1aa/0x280<br /> ? __pfx_rcu_torture_err_cb+0x10/0x10<br /> rt_spin_lock+0x53/0x130<br /> ? find_vmap_area+0x1f/0x70<br /> find_vmap_area+0x1f/0x70<br /> vmalloc_dump_obj+0x20/0x60<br /> mem_dump_obj+0x22/0x90<br /> __call_rcu_common+0x5bf/0x940<br /> ? debug_smp_processor_id+0x1b/0x30<br /> call_rcu_hurry+0x14/0x20<br /> rcu_torture_init+0x1f82/0x2370<br /> ? __pfx_rcu_torture_leak_cb+0x10/0x10<br /> ? __pfx_rcu_torture_leak_cb+0x10/0x10<br /> ? __pfx_rcu_torture_init+0x10/0x10<br /> do_one_initcall+0x6c/0x300<br /> ? debug_smp_processor_id+0x1b/0x30<br /> kernel_init_freeable+0x2b9/0x540<br /> ? __pfx_kernel_init+0x10/0x10<br /> kernel_init+0x1f/0x150<br /> ret_from_fork+0x40/0x50<br /> ? __pfx_kernel_init+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The previous patch fixes this by using the deadlock-safe best-effort<br /> version of find_vm_area. However, in case of failure print the fact that<br /> the pointer was a vmalloc pointer so that we print at least something.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nsh: Use correct mac_offset to unwind gso skb in nsh_gso_segment()<br /> <br /> As the call trace shows, skb_panic was caused by wrong skb-&gt;mac_header<br /> in nsh_gso_segment():<br /> <br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 3 PID: 2737 Comm: syz Not tainted 6.3.0-next-20230505 #1<br /> RIP: 0010:skb_panic+0xda/0xe0<br /> call Trace:<br /> skb_push+0x91/0xa0<br /> nsh_gso_segment+0x4f3/0x570<br /> skb_mac_gso_segment+0x19e/0x270<br /> __skb_gso_segment+0x1e8/0x3c0<br /> validate_xmit_skb+0x452/0x890<br /> validate_xmit_skb_list+0x99/0xd0<br /> sch_direct_xmit+0x294/0x7c0<br /> __dev_queue_xmit+0x16f0/0x1d70<br /> packet_xmit+0x185/0x210<br /> packet_snd+0xc15/0x1170<br /> packet_sendmsg+0x7b/0xa0<br /> sock_sendmsg+0x14f/0x160<br /> <br /> The root cause is:<br /> nsh_gso_segment() use skb-&gt;network_header - nhoff to reset mac_header<br /> in skb_gso_error_unwind() if inner-layer protocol gso fails.<br /> However, skb-&gt;network_header may be reset by inner-layer protocol<br /> gso function e.g. mpls_gso_segment. skb-&gt;mac_header reset by the<br /> inaccurate network_header will be larger than skb headroom.<br /> <br /> nsh_gso_segment<br /> nhoff = skb-&gt;network_header - skb-&gt;mac_header;<br /> __skb_pull(skb,nsh_len)<br /> skb_mac_gso_segment<br /> mpls_gso_segment<br /> skb_reset_network_header(skb);//skb-&gt;network_header+=nsh_len<br /> return -EINVAL;<br /> skb_gso_error_unwind<br /> skb_push(skb, nsh_len);<br /> skb-&gt;mac_header = skb-&gt;network_header - nhoff;<br /> // skb-&gt;mac_header &gt; skb-&gt;headroom, cause skb_push panic<br /> <br /> Use correct mac_offset to restore mac_header and get rid of nhoff.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pcmcia: rsrc_nonstatic: Fix memory leak in nonstatic_release_resource_db()<br /> <br /> When nonstatic_release_resource_db() frees all resources associated<br /> with an PCMCIA socket, it forgets to free socket_data too, causing<br /> a memory leak observable with kmemleak:<br /> <br /> unreferenced object 0xc28d1000 (size 64):<br /> comm "systemd-udevd", pid 297, jiffies 4294898478 (age 194.484s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 f0 85 0e c3 00 00 00 00 ................<br /> 00 00 00 00 0c 10 8d c2 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x2d7/0x4a0<br /> [] kmalloc_trace+0x31/0xa4<br /> [] nonstatic_init+0x24/0x1a4 [pcmcia_rsrc]<br /> [] pcmcia_register_socket+0x200/0x35c [pcmcia_core]<br /> [] yenta_probe+0x4d8/0xa70 [yenta_socket]<br /> [] pci_device_probe+0x99/0x194<br /> [] really_probe+0x181/0x45c<br /> [] __driver_probe_device+0x75/0x1f4<br /> [] driver_probe_device+0x28/0xac<br /> [] __driver_attach+0xeb/0x1e4<br /> [] bus_for_each_dev+0x61/0xb4<br /> [] driver_attach+0x1e/0x28<br /> [] bus_add_driver+0x102/0x20c<br /> [] driver_register+0x5b/0x120<br /> [] __pci_register_driver+0x44/0x4c<br /> [] __UNIQUE_ID___addressable_cleanup_module188+0x1c/0xfffff000 [iTCO_vendor_support]<br /> <br /> Fix this by freeing socket_data too.<br /> <br /> Tested on a Acer Travelmate 4002WLMi by manually binding/unbinding<br /> the yenta_cardbus driver (yenta_socket).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/fbdev-generic: prohibit potential out-of-bounds access<br /> <br /> The fbdev test of IGT may write after EOF, which lead to out-of-bound<br /> access for drm drivers with fbdev-generic. For example, run fbdev test<br /> on a x86+ast2400 platform, with 1680x1050 resolution, will cause the<br /> linux kernel hang with the following call trace:<br /> <br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> [IGT] fbdev: starting subtest eof<br /> Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]<br /> [IGT] fbdev: starting subtest nullptr<br /> <br /> RIP: 0010:memcpy_erms+0xa/0x20<br /> RSP: 0018:ffffa17d40167d98 EFLAGS: 00010246<br /> RAX: ffffa17d4eb7fa80 RBX: ffffa17d40e0aa80 RCX: 00000000000014c0<br /> RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000<br /> RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0<br /> R10: ffffa17d4e4c5000 R11: 0000000000000000 R12: ffffa17d4eb7fa80<br /> R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30<br /> FS: 0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]<br /> drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]<br /> process_one_work+0x21f/0x430<br /> worker_thread+0x4e/0x3c0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xf4/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> CR2: ffffa17d40e0b000<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The is because damage rectangles computed by<br /> drm_fb_helper_memory_range_to_clip() function is not guaranteed to be<br /> bound in the screen&amp;#39;s active display area. Possible reasons are:<br /> <br /> 1) Buffers are allocated in the granularity of page size, for mmap system<br /> call support. The shadow screen buffer consumed by fbdev emulation may<br /> also choosed be page size aligned.<br /> <br /> 2) The DIV_ROUND_UP() used in drm_fb_helper_memory_range_to_clip()<br /> will introduce off-by-one error.<br /> <br /> For example, on a 16KB page size system, in order to store a 1920x1080<br /> XRGB framebuffer, we need allocate 507 pages. Unfortunately, the size<br /> 1920*1080*4 can not be divided exactly by 16KB.<br /> <br /> 1920 * 1080 * 4 = 8294400 bytes<br /> 506 * 16 * 1024 = 8290304 bytes<br /> 507 * 16 * 1024 = 8306688 bytes<br /> <br /> line_length = 1920*4 = 7680 bytes<br /> <br /> 507 * 16 * 1024 / 7680 = 1081.6<br /> <br /> off / line_length = 507 * 16 * 1024 / 7680 = 1081<br /> DIV_ROUND_UP(507 * 16 * 1024, 7680) will yeild 1082<br /> <br /> memcpy_toio() typically issue the copy line by line, when copy the last<br /> line, out-of-bound access will be happen. Because:<br /> <br /> 1082 * line_length = 1082 * 7680 = 8309760, and 8309760 &gt; 8306688<br /> <br /> Note that userspace may still write to the invisiable area if a larger<br /> buffer than width x stride is exposed. But it is not a big issue as<br /> long as there still have memory resolve the access if not drafting so<br /> far.<br /> <br /> - Also limit the y1 (Daniel)<br /> - keep fix patch it to minimal (Daniel)<br /> - screen_size is page size aligned because of it need mmap (Thomas)<br /> - Adding fixes tag (Thomas)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/dcssblk: fix kernel crash with list_add corruption<br /> <br /> Commit fb08a1908cb1 ("dax: simplify the dax_device gendisk<br /> association") introduced new logic for gendisk association, requiring<br /> drivers to explicitly call dax_add_host() and dax_remove_host().<br /> <br /> For dcssblk driver, some dax_remove_host() calls were missing, e.g. in<br /> device remove path. The commit also broke error handling for out_dax case<br /> in device add path, resulting in an extra put_device() w/o the previous<br /> get_device() in that case.<br /> <br /> This lead to stale xarray entries after device add / remove cycles. In the<br /> case when a previously used struct gendisk pointer (xarray index) would be<br /> used again, because blk_alloc_disk() happened to return such a pointer, the<br /> xa_insert() in dax_add_host() would fail and go to out_dax, doing the extra<br /> put_device() in the error path. In combination with an already flawed error<br /> handling in dcssblk (device_register() cleanup), which needs to be<br /> addressed in a separate patch, this resulted in a missing device_del() /<br /> klist_del(), and eventually in the kernel crash with list_add corruption on<br /> a subsequent device_add() / klist_add().<br /> <br /> Fix this by adding the missing dax_remove_host() calls, and also move the<br /> put_device() in the error path to restore the previous logic.