Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: fix stack OOB read while fragmenting IPv4 packets<br /> <br /> running openvswitch on kernels built with KASAN, it&amp;#39;s possible to see the<br /> following splat while testing fragmentation of IPv4 packets:<br /> <br /> BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60<br /> Read of size 1 at addr ffff888112fc713c by task handler2/1367<br /> <br /> CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418<br /> Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014<br /> Call Trace:<br /> dump_stack+0x92/0xc1<br /> print_address_description.constprop.7+0x1a/0x150<br /> kasan_report.cold.13+0x7f/0x111<br /> ip_do_fragment+0x1b03/0x1f60<br /> ovs_fragment+0x5bf/0x840 [openvswitch]<br /> do_execute_actions+0x1bd5/0x2400 [openvswitch]<br /> ovs_execute_actions+0xc8/0x3d0 [openvswitch]<br /> ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch]<br /> genl_family_rcv_msg_doit.isra.15+0x227/0x2d0<br /> genl_rcv_msg+0x287/0x490<br /> netlink_rcv_skb+0x120/0x380<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x439/0x630<br /> netlink_sendmsg+0x719/0xbf0<br /> sock_sendmsg+0xe2/0x110<br /> ____sys_sendmsg+0x5ba/0x890<br /> ___sys_sendmsg+0xe9/0x160<br /> __sys_sendmsg+0xd3/0x170<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f957079db07<br /> Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48<br /> RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07<br /> RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019<br /> RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730<br /> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000<br /> R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0<br /> <br /> The buggy address belongs to the page:<br /> page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7<br /> flags: 0x17ffffc0000000()<br /> raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame:<br /> ovs_fragment+0x0/0x840 [openvswitch]<br /> <br /> this frame has 2 objects:<br /> [32, 144) &amp;#39;ovs_dst&amp;#39;<br /> [192, 424) &amp;#39;ovs_rt&amp;#39;<br /> <br /> Memory state around the buggy address:<br /> ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00<br /> ^<br /> ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00<br /> <br /> for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then,<br /> in the following call graph:<br /> <br /> ip_do_fragment()<br /> ip_skb_dst_mtu()<br /> ip_dst_mtu_maybe_forward()<br /> ip_mtu_locked()<br /> <br /> the pointer to struct dst_entry is used as pointer to struct rtable: this<br /> turns the access to struct members like rt_mtu_locked into an OOB read in<br /> the stack. Fix this changing the temporary variable used for IPv4 packets<br /> in ovs_fragment(), similarly to what is done for IPv6 few lines below.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtiofs: fix memory leak in virtio_fs_probe()<br /> <br /> When accidentally passing twice the same tag to qemu, kmemleak ended up<br /> reporting a memory leak in virtiofs. Also, looking at the log I saw the<br /> following error (that&amp;#39;s when I realised the duplicated tag):<br /> <br /> virtiofs: probe of virtio5 failed with error -17<br /> <br /> Here&amp;#39;s the kmemleak log for reference:<br /> <br /> unreferenced object 0xffff888103d47800 (size 1024):<br /> comm "systemd-udevd", pid 118, jiffies 4294893780 (age 18.340s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff ................<br /> backtrace:<br /> [] virtio_fs_probe+0x171/0x7ae [virtiofs]<br /> [] virtio_dev_probe+0x15f/0x210<br /> [] really_probe+0xea/0x430<br /> [] device_driver_attach+0xa8/0xb0<br /> [] __driver_attach+0x98/0x140<br /> [] bus_for_each_dev+0x7b/0xc0<br /> [] bus_add_driver+0x11b/0x1f0<br /> [] driver_register+0x8f/0xe0<br /> [] 0xffffffffa002c013<br /> [] do_one_initcall+0x64/0x2e0<br /> [] do_init_module+0x5c/0x260<br /> [] __do_sys_finit_module+0xb5/0x120<br /> [] do_syscall_64+0x33/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv/kprobe: fix kernel panic when invoking sys_read traced by kprobe<br /> <br /> The execution of sys_read end up hitting a BUG_ON() in __find_get_block<br /> after installing kprobe at sys_read, the BUG message like the following:<br /> <br /> [ 65.708663] ------------[ cut here ]------------<br /> [ 65.709987] kernel BUG at fs/buffer.c:1251!<br /> [ 65.711283] Kernel BUG [#1]<br /> [ 65.712032] Modules linked in:<br /> [ 65.712925] CPU: 0 PID: 51 Comm: sh Not tainted 5.12.0-rc4 #1<br /> [ 65.714407] Hardware name: riscv-virtio,qemu (DT)<br /> [ 65.715696] epc : __find_get_block+0x218/0x2c8<br /> [ 65.716835] ra : __getblk_gfp+0x1c/0x4a<br /> [ 65.717831] epc : ffffffe00019f11e ra : ffffffe00019f56a sp : ffffffe002437930<br /> [ 65.719553] gp : ffffffe000f06030 tp : ffffffe0015abc00 t0 : ffffffe00191e038<br /> [ 65.721290] t1 : ffffffe00191e038 t2 : 000000000000000a s0 : ffffffe002437960<br /> [ 65.723051] s1 : ffffffe00160ad00 a0 : ffffffe00160ad00 a1 : 000000000000012a<br /> [ 65.724772] a2 : 0000000000000400 a3 : 0000000000000008 a4 : 0000000000000040<br /> [ 65.726545] a5 : 0000000000000000 a6 : ffffffe00191e000 a7 : 0000000000000000<br /> [ 65.728308] s2 : 000000000000012a s3 : 0000000000000400 s4 : 0000000000000008<br /> [ 65.730049] s5 : 000000000000006c s6 : ffffffe00240f800 s7 : ffffffe000f080a8<br /> [ 65.731802] s8 : 0000000000000001 s9 : 000000000000012a s10: 0000000000000008<br /> [ 65.733516] s11: 0000000000000008 t3 : 00000000000003ff t4 : 000000000000000f<br /> [ 65.734434] t5 : 00000000000003ff t6 : 0000000000040000<br /> [ 65.734613] status: 0000000000000100 badaddr: 0000000000000000 cause: 0000000000000003<br /> [ 65.734901] Call Trace:<br /> [ 65.735076] [] __find_get_block+0x218/0x2c8<br /> [ 65.735417] [] __ext4_get_inode_loc+0xb2/0x2f6<br /> [ 65.735618] [] ext4_get_inode_loc+0x3a/0x8a<br /> [ 65.735802] [] ext4_reserve_inode_write+0x2e/0x8c<br /> [ 65.735999] [] __ext4_mark_inode_dirty+0x4c/0x18e<br /> [ 65.736208] [] ext4_dirty_inode+0x46/0x66<br /> [ 65.736387] [] __mark_inode_dirty+0x12c/0x3da<br /> [ 65.736576] [] touch_atime+0x146/0x150<br /> [ 65.736748] [] filemap_read+0x234/0x246<br /> [ 65.736920] [] generic_file_read_iter+0xc0/0x114<br /> [ 65.737114] [] ext4_file_read_iter+0x42/0xea<br /> [ 65.737310] [] new_sync_read+0xe2/0x15a<br /> [ 65.737483] [] vfs_read+0xca/0xf2<br /> [ 65.737641] [] ksys_read+0x5e/0xc8<br /> [ 65.737816] [] sys_read+0xe/0x16<br /> [ 65.737973] [] ret_from_syscall+0x0/0x2<br /> [ 65.738858] ---[ end trace fe93f985456c935d ]---<br /> <br /> A simple reproducer looks like:<br /> echo &amp;#39;p:myprobe sys_read fd=%a0 buf=%a1 count=%a2&amp;#39; &gt; /sys/kernel/debug/tracing/kprobe_events<br /> echo 1 &gt; /sys/kernel/debug/tracing/events/kprobes/myprobe/enable<br /> cat /sys/kernel/debug/tracing/trace<br /> <br /> Here&amp;#39;s what happens to hit that BUG_ON():<br /> <br /> 1) After installing kprobe at entry of sys_read, the first instruction<br /> is replaced by &amp;#39;ebreak&amp;#39; instruction on riscv64 platform.<br /> <br /> 2) Once kernel reach the &amp;#39;ebreak&amp;#39; instruction at the entry of sys_read,<br /> it trap into the riscv breakpoint handler, where it do something to<br /> setup for coming single-step of origin instruction, including backup<br /> the &amp;#39;sstatus&amp;#39; in pt_regs, followed by disable interrupt during single<br /> stepping via clear &amp;#39;SIE&amp;#39; bit of &amp;#39;sstatus&amp;#39; in pt_regs.<br /> <br /> 3) Then kernel restore to the instruction slot contains two instructions,<br /> one is original instruction at entry of sys_read, the other is &amp;#39;ebreak&amp;#39;.<br /> Here it trigger a &amp;#39;Instruction page fault&amp;#39; exception (value at &amp;#39;scause&amp;#39;<br /> is &amp;#39;0xc&amp;#39;), if PF is not filled into PageTabe for that slot yet.<br /> <br /> 4) Again kernel trap into page fault exception handler, where it choose<br /> different policy according to the state of running kprobe. Because<br /> afte 2) the state is KPROBE_HIT_SS, so kernel reset the current kp<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race between transaction aborts and fsyncs leading to use-after-free<br /> <br /> There is a race between a task aborting a transaction during a commit,<br /> a task doing an fsync and the transaction kthread, which leads to an<br /> use-after-free of the log root tree. When this happens, it results in a<br /> stack trace like the following:<br /> <br /> BTRFS info (device dm-0): forced readonly<br /> BTRFS warning (device dm-0): Skipping commit of aborted transaction.<br /> BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure<br /> BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5)<br /> BTRFS warning (device dm-0): Skipping commit of aborted transaction.<br /> BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10<br /> BTRFS error (device dm-0): error writing primary super block to device 1<br /> BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10<br /> BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10<br /> BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10<br /> BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers)<br /> BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure<br /> general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI<br /> CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__mutex_lock+0x139/0xa40<br /> Code: c0 74 19 (...)<br /> RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202<br /> RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002<br /> RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040<br /> R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358<br /> FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ? __btrfs_handle_fs_error+0xde/0x146 [btrfs]<br /> ? btrfs_sync_log+0x7c1/0xf20 [btrfs]<br /> ? btrfs_sync_log+0x7c1/0xf20 [btrfs]<br /> btrfs_sync_log+0x7c1/0xf20 [btrfs]<br /> btrfs_sync_file+0x40c/0x580 [btrfs]<br /> do_fsync+0x38/0x70<br /> __x64_sys_fsync+0x10/0x20<br /> do_syscall_64+0x33/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fa9142a55c3<br /> Code: 8b 15 09 (...)<br /> RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a<br /> RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3<br /> RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005<br /> RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340<br /> R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0<br /> Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...)<br /> ---[ end trace ee2f1b19327d791d ]---<br /> <br /> The steps that lead to this crash are the following:<br /> <br /> 1) We are at transaction N;<br /> <br /> 2) We have two tasks with a transaction handle attached to transaction N.<br /> Task A and Task B. Task B is doing an fsync;<br /> <br /> 3) Task B is at btrfs_sync_log(), and has saved fs_info-&gt;log_root_tree<br /> into a local variable named &amp;#39;log_root_tree&amp;#39; at the top of<br /> btrfs_sync_log(). Task B is about to call write_all_supers(), but<br /> before that...<br /> <br /> 4) Task A calls btrfs_commit_transaction(), and after it sets the<br /> transaction state to TRANS_STATE_COMMIT_START, an error happens before<br /> it w<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Return correct error code from smb2_get_enc_key<br /> <br /> Avoid a warning if the error percolates back up:<br /> <br /> [440700.376476] CIFS VFS: \\otters.example.com crypt_message: Could not get encryption key<br /> [440700.386947] ------------[ cut here ]------------<br /> [440700.386948] err = 1<br /> [440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70<br /> ...<br /> [440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu<br /> ...<br /> [440700.397334] Call Trace:<br /> [440700.397346] __filemap_set_wb_err+0x1a/0x70<br /> [440700.397419] cifs_writepages+0x9c7/0xb30 [cifs]<br /> [440700.397426] do_writepages+0x4b/0xe0<br /> [440700.397444] __filemap_fdatawrite_range+0xcb/0x100<br /> [440700.397455] filemap_write_and_wait+0x42/0xa0<br /> [440700.397486] cifs_setattr+0x68b/0xf30 [cifs]<br /> [440700.397493] notify_change+0x358/0x4a0<br /> [440700.397500] utimes_common+0xe9/0x1c0<br /> [440700.397510] do_utimes+0xc5/0x150<br /> [440700.397520] __x64_sys_utimensat+0x88/0xd0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v3: Do not enable irqs when handling spurious interrups<br /> <br /> We triggered the following error while running our 4.19 kernel<br /> with the pseudo-NMI patches backported to it:<br /> <br /> [ 14.816231] ------------[ cut here ]------------<br /> [ 14.816231] kernel BUG at irq.c:99!<br /> [ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP<br /> [ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____))<br /> [ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14<br /> [ 14.816233] Hardware name: evb (DT)<br /> [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)<br /> [ 14.816234] pc : asm_nmi_enter+0x94/0x98<br /> [ 14.816235] lr : asm_nmi_enter+0x18/0x98<br /> [ 14.816235] sp : ffff000008003c50<br /> [ 14.816235] pmr_save: 00000070<br /> [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0<br /> [ 14.816238] x27: 0000000000000000 x26: ffff000008004000<br /> [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000<br /> [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc<br /> [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060<br /> [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff<br /> [ 14.816243] x17: 0000000000000008 x16: 003d090000000000<br /> [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40<br /> [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000<br /> [ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5<br /> [ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f<br /> [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e<br /> [ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000<br /> [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000<br /> [ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0<br /> [ 14.816251] Call trace:<br /> [ 14.816251] asm_nmi_enter+0x94/0x98<br /> [ 14.816251] el1_irq+0x8c/0x180 (IRQ C)<br /> [ 14.816252] gic_handle_irq+0xbc/0x2e4<br /> [ 14.816252] el1_irq+0xcc/0x180 (IRQ B)<br /> [ 14.816253] arch_timer_handler_virt+0x38/0x58<br /> [ 14.816253] handle_percpu_devid_irq+0x90/0x240<br /> [ 14.816253] generic_handle_irq+0x34/0x50<br /> [ 14.816254] __handle_domain_irq+0x68/0xc0<br /> [ 14.816254] gic_handle_irq+0xf8/0x2e4<br /> [ 14.816255] el1_irq+0xcc/0x180 (IRQ A)<br /> [ 14.816255] arch_cpu_idle+0x34/0x1c8<br /> [ 14.816255] default_idle_call+0x24/0x44<br /> [ 14.816256] do_idle+0x1d0/0x2c8<br /> [ 14.816256] cpu_startup_entry+0x28/0x30<br /> [ 14.816256] rest_init+0xb8/0xc8<br /> [ 14.816257] start_kernel+0x4c8/0x4f4<br /> [ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)<br /> [ 14.816258] Modules linked in: start_dp(O) smeth(O)<br /> [ 15.103092] ---[ end trace 701753956cb14aa8 ]---<br /> [ 15.103093] Kernel panic - not syncing: Fatal exception in interrupt<br /> [ 15.103099] SMP: stopping secondary CPUs<br /> [ 15.103100] Kernel Offset: disabled<br /> [ 15.103100] CPU features: 0x36,a2400218<br /> [ 15.103100] Memory Limit: none<br /> <br /> which is cause by a &amp;#39;BUG_ON(in_nmi())&amp;#39; in nmi_enter().<br /> <br /> From the call trace, we can find three interrupts (noted A, B, C above):<br /> interrupt (A) is preempted by (B), which is further interrupted by (C).<br /> <br /> Subsequent investigations show that (B) results in nmi_enter() being<br /> called, but that it actually is a spurious interrupt. Furthermore,<br /> interrupts are reenabled in the context of (B), and (C) fires with<br /> NMI priority. We end-up with a nested NMI situation, something<br /> we definitely do not want to (and cannot) handle.<br /> <br /> The bug here is that spurious interrupts should never result in any<br /> state change, and we should just return to the interrupted context.<br /> Moving the handling of spurious interrupts as early as possible in<br /> the GICv3 handler fixes this issue.<br /> <br /> [maz: rewrote commit message, corrected Fixes: tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: uniphier-sd: Fix a resource leak in the remove function<br /> <br /> A &amp;#39;tmio_mmc_host_free()&amp;#39; call is missing in the remove function, in order<br /> to balance a &amp;#39;tmio_mmc_host_alloc()&amp;#39; call in the probe.<br /> This is done in the error handling path of the probe, but not in the remove<br /> function.<br /> <br /> Add the missing call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal/drivers/cpufreq_cooling: Fix slab OOB issue<br /> <br /> Slab OOB issue is scanned by KASAN in cpu_power_to_freq().<br /> If power is limited below the power of OPP0 in EM table,<br /> it will cause slab out-of-bound issue with negative array<br /> index.<br /> <br /> Return the lowest frequency if limited power cannot found<br /> a suitable OPP in EM table to fix this issue.<br /> <br /> Backtrace:<br /> [] die+0x104/0x5ac<br /> [] bug_handler+0x64/0xd0<br /> [] brk_handler+0x160/0x258<br /> [] do_debug_exception+0x248/0x3f0<br /> [] el1_dbg+0x14/0xbc<br /> [] __kasan_report+0x1dc/0x1e0<br /> [] kasan_report+0x10/0x20<br /> [] __asan_report_load8_noabort+0x18/0x28<br /> [] cpufreq_power2state+0x180/0x43c<br /> [] power_actor_set_power+0x114/0x1d4<br /> [] allocate_power+0xaec/0xde0<br /> [] power_allocator_throttle+0x3ec/0x5a4<br /> [] handle_thermal_trip+0x160/0x294<br /> [] thermal_zone_device_check+0xe4/0x154<br /> [] process_one_work+0x5e4/0xe28<br /> [] worker_thread+0xa4c/0xfac<br /> [] kthread+0x33c/0x358<br /> [] ret_from_fork+0xc/0x18

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvbdev: Fix memory leak in dvb_media_device_free()<br /> <br /> dvb_media_device_free() is leaking memory. Free `dvbdev-&gt;adapter-&gt;conn`<br /> before setting it to NULL, as documented in include/media/media-device.h:<br /> "The media_entity instance itself must be freed explicitly by the driver<br /> if required."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails<br /> <br /> When loading a device-mapper table for a request-based mapped device,<br /> and the allocation/initialization of the blk_mq_tag_set for the device<br /> fails, a following device remove will cause a double free.<br /> <br /> E.g. (dmesg):<br /> device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device<br /> device-mapper: ioctl: unable to set up device queue for new table.<br /> Unable to handle kernel pointer dereference in virtual kernel address space<br /> Failing address: 0305e098835de000 TEID: 0305e098835de803<br /> Fault in home space mode while using kernel ASCE.<br /> AS:000000025efe0007 R3:0000000000000024<br /> Oops: 0038 ilc:3 [#1] SMP<br /> Modules linked in: ... lots of modules ...<br /> Supported: Yes, External<br /> CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3<br /> Hardware name: IBM 8561 T01 7I2 (LPAR)<br /> Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330)<br /> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3<br /> Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000<br /> 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000<br /> 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640<br /> 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8<br /> Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8<br /> 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58<br /> #000000025e368ec4: e3b010000008 ag %r11,0(%r1)<br /> &gt;000000025e368eca: e310b0080004 lg %r1,8(%r11)<br /> 000000025e368ed0: a7110001 tmll %r1,1<br /> 000000025e368ed4: a7740129 brc 7,25e369126<br /> 000000025e368ed8: e320b0080004 lg %r2,8(%r11)<br /> 000000025e368ede: b904001b lgr %r1,%r11<br /> Call Trace:<br /> [] kfree+0x42/0x330<br /> [] blk_mq_free_tag_set+0x72/0xb8<br /> [] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod]<br /> [] free_dev+0x52/0xd0 [dm_mod]<br /> [] __dm_destroy+0x150/0x1d0 [dm_mod]<br /> [] dev_remove+0x162/0x1c0 [dm_mod]<br /> [] ctl_ioctl+0x198/0x478 [dm_mod]<br /> [] dm_ctl_ioctl+0x22/0x38 [dm_mod]<br /> [] ksys_ioctl+0xbe/0xe0<br /> [] __s390x_sys_ioctl+0x2a/0x40<br /> [] system_call+0xd8/0x2c8<br /> Last Breaking-Event-Address:<br /> [] blk_mq_free_tag_set+0x6c/0xb8<br /> Kernel panic - not syncing: Fatal exception: panic_on_oops<br /> <br /> When allocation/initialization of the blk_mq_tag_set fails in<br /> dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer<br /> is not reset to NULL; so when dev_remove() later gets into<br /> dm_mq_cleanup_mapped_device() it sees the pointer and tries to<br /> uninitialize and free it again.<br /> <br /> Fix this by setting the pointer to NULL in dm_mq_init_request_queue()<br /> error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Restructure trace_clock_global() to never block<br /> <br /> It was reported that a fix to the ring buffer recursion detection would<br /> cause a hung machine when performing suspend / resume testing. The<br /> following backtrace was extracted from debugging that case:<br /> <br /> Call Trace:<br /> trace_clock_global+0x91/0xa0<br /> __rb_reserve_next+0x237/0x460<br /> ring_buffer_lock_reserve+0x12a/0x3f0<br /> trace_buffer_lock_reserve+0x10/0x50<br /> __trace_graph_return+0x1f/0x80<br /> trace_graph_return+0xb7/0xf0<br /> ? trace_clock_global+0x91/0xa0<br /> ftrace_return_to_handler+0x8b/0xf0<br /> ? pv_hash+0xa0/0xa0<br /> return_to_handler+0x15/0x30<br /> ? ftrace_graph_caller+0xa0/0xa0<br /> ? trace_clock_global+0x91/0xa0<br /> ? __rb_reserve_next+0x237/0x460<br /> ? ring_buffer_lock_reserve+0x12a/0x3f0<br /> ? trace_event_buffer_lock_reserve+0x3c/0x120<br /> ? trace_event_buffer_reserve+0x6b/0xc0<br /> ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0<br /> ? dpm_run_callback+0x3b/0xc0<br /> ? pm_ops_is_empty+0x50/0x50<br /> ? platform_get_irq_byname_optional+0x90/0x90<br /> ? trace_device_pm_callback_start+0x82/0xd0<br /> ? dpm_run_callback+0x49/0xc0<br /> <br /> With the following RIP:<br /> <br /> RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200<br /> <br /> Since the fix to the recursion detection would allow a single recursion to<br /> happen while tracing, this lead to the trace_clock_global() taking a spin<br /> lock and then trying to take it again:<br /> <br /> ring_buffer_lock_reserve() {<br /> trace_clock_global() {<br /> arch_spin_lock() {<br /> queued_spin_lock_slowpath() {<br /> /* lock taken */<br /> (something else gets traced by function graph tracer)<br /> ring_buffer_lock_reserve() {<br /> trace_clock_global() {<br /> arch_spin_lock() {<br /> queued_spin_lock_slowpath() {<br /> /* DEAD LOCK! */<br /> <br /> Tracing should *never* block, as it can lead to strange lockups like the<br /> above.<br /> <br /> Restructure the trace_clock_global() code to instead of simply taking a<br /> lock to update the recorded "prev_time" simply use it, as two events<br /> happening on two different CPUs that calls this at the same time, really<br /> doesn&amp;#39;t matter which one goes first. Use a trylock to grab the lock for<br /> updating the prev_time, and if it fails, simply try again the next time.<br /> If it failed to be taken, that means something else is already updating<br /> it.<br /> <br /> <br /> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tools/power turbostat: Fix offset overflow issue in index converting<br /> <br /> The idx_to_offset() function returns type int (32-bit signed), but<br /> MSR_PKG_ENERGY_STAT is u32 and would be interpreted as a negative number.<br /> The end result is that it hits the if (offset