Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: arm64/neonbs - fix out-of-bounds access on short input<br /> <br /> The bit-sliced implementation of AES-CTR operates on blocks of 128<br /> bytes, and will fall back to the plain NEON version for tail blocks or<br /> inputs that are shorter than 128 bytes to begin with.<br /> <br /> It will call straight into the plain NEON asm helper, which performs all<br /> memory accesses in granules of 16 bytes (the size of a NEON register).<br /> For this reason, the associated plain NEON glue code will copy inputs<br /> shorter than 16 bytes into a temporary buffer, given that this is a rare<br /> occurrence and it is not worth the effort to work around this in the asm<br /> code.<br /> <br /> The fallback from the bit-sliced NEON version fails to take this into<br /> account, potentially resulting in out-of-bounds accesses. So clone the<br /> same workaround, and use a temp buffer for short in/outputs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read<br /> <br /> There is chip (ls1028a) errata:<br /> <br /> The SoC may hang on 16 byte unaligned read transactions by QDMA.<br /> <br /> Unaligned read transactions initiated by QDMA may stall in the NOC<br /> (Network On-Chip), causing a deadlock condition. Stalled transactions will<br /> trigger completion timeouts in PCIe controller.<br /> <br /> Workaround:<br /> Enable prefetch by setting the source descriptor prefetchable bit<br /> ( SD[PF] = 1 ).<br /> <br /> Implement this workaround.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: dev-replace: properly validate device names<br /> <br /> There&amp;#39;s a syzbot report that device name buffers passed to device<br /> replace are not properly checked for string termination which could lead<br /> to a read out of bounds in getname_kernel().<br /> <br /> Add a helper that validates both source and target device name buffers.<br /> For devid as the source initialize the buffer to empty string in case<br /> something tries to read it later.<br /> <br /> This was originally analyzed and fixed in a different way by Edward Adam<br /> Davis (see links).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix double free of anonymous device after snapshot creation failure<br /> <br /> When creating a snapshot we may do a double free of an anonymous device<br /> in case there&amp;#39;s an error committing the transaction. The second free may<br /> result in freeing an anonymous device number that was allocated by some<br /> other subsystem in the kernel or another btrfs filesystem.<br /> <br /> The steps that lead to this:<br /> <br /> 1) At ioctl.c:create_snapshot() we allocate an anonymous device number<br /> and assign it to pending_snapshot-&gt;anon_dev;<br /> <br /> 2) Then we call btrfs_commit_transaction() and end up at<br /> transaction.c:create_pending_snapshot();<br /> <br /> 3) There we call btrfs_get_new_fs_root() and pass it the anonymous device<br /> number stored in pending_snapshot-&gt;anon_dev;<br /> <br /> 4) btrfs_get_new_fs_root() frees that anonymous device number because<br /> btrfs_lookup_fs_root() returned a root - someone else did a lookup<br /> of the new root already, which could some task doing backref walking;<br /> <br /> 5) After that some error happens in the transaction commit path, and at<br /> ioctl.c:create_snapshot() we jump to the &amp;#39;fail&amp;#39; label, and after<br /> that we free again the same anonymous device number, which in the<br /> meanwhile may have been reallocated somewhere else, because<br /> pending_snapshot-&gt;anon_dev still has the same value as in step 1.<br /> <br /> Recently syzbot ran into this and reported the following trace:<br /> <br /> ------------[ cut here ]------------<br /> ida_free called for id=51 which is not allocated.<br /> WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525<br /> Modules linked in:<br /> CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024<br /> RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525<br /> Code: 10 42 80 3c 28 (...)<br /> RSP: 0018:ffffc90015a67300 EFLAGS: 00010246<br /> RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000<br /> RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000<br /> RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4<br /> R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246<br /> R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246<br /> FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346<br /> create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837<br /> create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931<br /> btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404<br /> create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848<br /> btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998<br /> btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044<br /> __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306<br /> btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393<br /> btrfs_ioctl+0xa74/0xd40<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:871 [inline]<br /> __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857<br /> do_syscall_64+0xfb/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> RIP: 0033:0x7fca3e67dda9<br /> Code: 28 00 00 00 (...)<br /> RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9<br /> RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003<br /> RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658<br /> <br /> <br /> Where we get an explicit message where we attempt to free an anonymous<br /> device number that is not currently allocated. It happens in a different<br /> code path from the example below, at btrfs_get_root_ref(), so this change<br /> may not fix the case triggered by sy<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: fix use-after-free and null-ptr-deref in gtp_newlink()<br /> <br /> The gtp_link_ops operations structure for the subsystem must be<br /> registered after registering the gtp_net_ops pernet operations structure.<br /> <br /> Syzkaller hit &amp;#39;general protection fault in gtp_genl_dump_pdp&amp;#39; bug:<br /> <br /> [ 1010.702740] gtp: GTP module unloaded<br /> [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI<br /> [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1<br /> [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014<br /> [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]<br /> [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00<br /> [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203<br /> [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000<br /> [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282<br /> [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000<br /> [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80<br /> [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400<br /> [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000<br /> [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0<br /> [ 1010.715968] PKRU: 55555554<br /> [ 1010.715972] Call Trace:<br /> [ 1010.715985] ? __die_body.cold+0x1a/0x1f<br /> [ 1010.715995] ? die_addr+0x43/0x70<br /> [ 1010.716002] ? exc_general_protection+0x199/0x2f0<br /> [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30<br /> [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]<br /> [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]<br /> [ 1010.716042] __rtnl_newlink+0x1063/0x1700<br /> [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0<br /> [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0<br /> [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0<br /> [ 1010.716076] ? __kernel_text_address+0x56/0xa0<br /> [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0<br /> [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30<br /> [ 1010.716098] ? arch_stack_walk+0x9e/0xf0<br /> [ 1010.716106] ? stack_trace_save+0x91/0xd0<br /> [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170<br /> [ 1010.716121] ? __lock_acquire+0x15c5/0x5380<br /> [ 1010.716139] ? mark_held_locks+0x9e/0xe0<br /> [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0<br /> [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700<br /> [ 1010.716160] rtnl_newlink+0x69/0xa0<br /> [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50<br /> [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0<br /> [ 1010.716179] ? lock_acquire+0x1fe/0x560<br /> [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50<br /> [ 1010.716196] netlink_rcv_skb+0x14d/0x440<br /> [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0<br /> [ 1010.716208] ? netlink_ack+0xab0/0xab0<br /> [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50<br /> [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50<br /> [ 1010.716226] ? __virt_addr_valid+0x30b/0x590<br /> [ 1010.716233] netlink_unicast+0x54b/0x800<br /> [ 1010.716240] ? netlink_attachskb+0x870/0x870<br /> [ 1010.716248] ? __check_object_size+0x2de/0x3b0<br /> [ 1010.716254] netlink_sendmsg+0x938/0xe40<br /> [ 1010.716261] ? netlink_unicast+0x800/0x800<br /> [ 1010.716269] ? __import_iovec+0x292/0x510<br /> [ 1010.716276] ? netlink_unicast+0x800/0x800<br /> [ 1010.716284] __sock_sendmsg+0x159/0x190<br /> [ 1010.716290] ____sys_sendmsg+0x712/0x880<br /> [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0<br /> [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270<br /> [ 1010.716309] ? lock_acquire+0x1fe/0x560<br /> [ 1010.716315] ? drain_array_locked+0x90/0x90<br /> [ 1010.716324] ___sys_sendmsg+0xf8/0x170<br /> [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170<br /> [ 1010.716337] ? lockdep_init_map<br /> ---truncated---

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 /> riscv: Sparse-Memory/vmemmap out-of-bounds fix<br /> <br /> Offset vmemmap so that the first page of vmemmap will be mapped<br /> to the first page of physical memory in order to ensure that<br /> vmemmap’s bounds will be respected during<br /> pfn_to_page()/page_to_pfn() operations.<br /> The conversion macros will produce correct SV39/48/57 addresses<br /> for every possible/valid DRAM_BASE inside the physical memory limits.<br /> <br /> v2:Address Alex&amp;#39;s comments

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: perf: ctr_get_width function for legacy is not defined<br /> <br /> With parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n<br /> linux kernel crashes when you try perf record:<br /> <br /> $ perf record ls<br /> [ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 46.750199] Oops [#1]<br /> [ 46.750342] Modules linked in:<br /> [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2<br /> [ 46.750906] Hardware name: riscv-virtio,qemu (DT)<br /> [ 46.751184] epc : 0x0<br /> [ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e<br /> [ 46.751680] epc : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0<br /> [ 46.751958] gp : ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0<br /> [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930<br /> [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 : ff600000028fb000<br /> [ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004<br /> [ 46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2<br /> [ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000<br /> [ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff60000002961078<br /> [ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10: 0000000000000001<br /> [ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff<br /> [ 46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30<br /> [ 46.754179] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000c<br /> [ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec.<br /> [ 46.754939] ---[ end trace 0000000000000000 ]---<br /> [ 46.755131] note: perf-exec[107] exited with irqs disabled<br /> [ 46.755546] note: perf-exec[107] exited with preempt_count 4<br /> <br /> This happens because in the legacy case the ctr_get_width function was not<br /> defined, but it is used in arch_perf_update_userpage.<br /> <br /> Also remove extra check in riscv_pmu_ctr_get_width_mask

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Prevent potential buffer overflow in map_hw_resources<br /> <br /> Adds a check in the map_hw_resources function to prevent a potential<br /> buffer overflow. The function was accessing arrays using an index that<br /> could potentially be greater than the size of the arrays, leading to a<br /> buffer overflow.<br /> <br /> Adds a check to ensure that the index is within the bounds of the<br /> arrays. If the index is out of bounds, an error message is printed and<br /> break it will continue execution with just ignoring extra data early to<br /> prevent the buffer overflow.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 map_hw_resources() error: buffer overflow &amp;#39;dml2-&gt;v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id&amp;#39; 6 v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id&amp;#39; 6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: Fix uninitialized pointer dmactl<br /> <br /> In the case where __lpass_get_dmactl_handle is called and the driver<br /> id dai_id is invalid the pointer dmactl is not being assigned a value,<br /> and dmactl contains a garbage value since it has not been initialized<br /> and so the null check may not work. Fix this to initialize dmactl to<br /> NULL. One could argue that modern compilers will set this to zero, but<br /> it is useful to keep this initialized as per the same way in functions<br /> __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params.<br /> <br /> Cleans up clang scan build warning:<br /> sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition<br /> evaluates to a garbage value [core.uninitialized.Branch]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index<br /> <br /> With numa balancing on, when a numa system is running where a numa node<br /> doesn&amp;#39;t have its local memory so it has no managed zones, the following<br /> oops has been observed. It&amp;#39;s because wakeup_kswapd() is called with a<br /> wrong zone index, -1. Fixed it by checking the index before calling<br /> wakeup_kswapd().<br /> <br /> &gt; BUG: unable to handle page fault for address: 00000000000033f3<br /> &gt; #PF: supervisor read access in kernel mode<br /> &gt; #PF: error_code(0x0000) - not-present page<br /> &gt; PGD 0 P4D 0<br /> &gt; Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> &gt; CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255<br /> &gt; Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> &gt; rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> &gt; RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812)<br /> &gt; Code: (omitted)<br /> &gt; RSP: 0000:ffffc90004257d58 EFLAGS: 00010286<br /> &gt; RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003<br /> &gt; RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480<br /> &gt; RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff<br /> &gt; R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003<br /> &gt; R13: 0000000000000000 R14: 0000000000000000 R15: ffff88883fff0940<br /> &gt; FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000<br /> &gt; CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> &gt; CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0<br /> &gt; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> &gt; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> &gt; PKRU: 55555554<br /> &gt; Call Trace:<br /> &gt; <br /> &gt; ? __die<br /> &gt; ? page_fault_oops<br /> &gt; ? __pte_offset_map_lock<br /> &gt; ? exc_page_fault<br /> &gt; ? asm_exc_page_fault<br /> &gt; ? wakeup_kswapd<br /> &gt; migrate_misplaced_page<br /> &gt; __handle_mm_fault<br /> &gt; handle_mm_fault<br /> &gt; do_user_addr_fault<br /> &gt; exc_page_fault<br /> &gt; asm_exc_page_fault<br /> &gt; RIP: 0033:0x55b897ba0808<br /> &gt; Code: (omitted)<br /> &gt; RSP: 002b:00007ffeefa821a0 EFLAGS: 00010287<br /> &gt; RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0<br /> &gt; RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0<br /> &gt; RBP: 00007ffeefa821a0 R08: 0000000000000037 R09: 0000000000000075<br /> &gt; R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000<br /> &gt; R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000<br /> &gt;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: always restore the old font data in fbcon_do_set_font()<br /> <br /> Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when<br /> vc_resize() failed) started restoring old font data upon failure (of<br /> vc_resize()). But it performs so only for user fonts. It means that the<br /> "system"/internal fonts are not restored at all. So in result, the very<br /> first call to fbcon_do_set_font() performs no restore at all upon<br /> failing vc_resize().<br /> <br /> This can be reproduced by Syzkaller to crash the system on the next<br /> invocation of font_get(). It&amp;#39;s rather hard to hit the allocation failure<br /> in vc_resize() on the first font_set(), but not impossible. Esp. if<br /> fault injection is used to aid the execution/failure. It was<br /> demonstrated by Sirius:<br /> BUG: unable to handle page fault for address: fffffffffffffff8<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286<br /> Call Trace:<br /> <br /> con_font_get drivers/tty/vt/vt.c:4558 [inline]<br /> con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673<br /> vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]<br /> vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752<br /> tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> ...<br /> <br /> So restore the font data in any case, not only for user fonts. Note the<br /> later &amp;#39;if&amp;#39; is now protected by &amp;#39;old_userfont&amp;#39; and not &amp;#39;old_data&amp;#39; as the<br /> latter is always set now. (And it is supposed to be non-NULL. Otherwise<br /> we would see the bug above again.)