Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: fix memory leak in jffs2_scan_medium<br /> <br /> If an error is returned in jffs2_scan_eraseblock() and some memory<br /> has been added to the jffs2_summary *s, we can observe the following<br /> kmemleak report:<br /> <br /> --------------------------------------------<br /> unreferenced object 0xffff88812b889c40 (size 64):<br /> comm "mount", pid 692, jiffies 4294838325 (age 34.288s)<br /> hex dump (first 32 bytes):<br /> 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.<br /> 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................<br /> backtrace:<br /> [] __kmalloc+0x613/0x910<br /> [] jffs2_sum_add_dirent_mem+0x5c/0xa0<br /> [] jffs2_scan_medium.cold+0x36e5/0x4794<br /> [] jffs2_do_mount_fs.cold+0xa7/0x2267<br /> [] jffs2_do_fill_super+0x383/0xc30<br /> [] jffs2_fill_super+0x2ea/0x4c0<br /> [] mtd_get_sb+0x254/0x400<br /> [] mtd_get_sb_by_nr+0x4f/0xd0<br /> [] get_tree_mtd+0x498/0x840<br /> [] jffs2_get_tree+0x25/0x30<br /> [] vfs_get_tree+0x8d/0x2e0<br /> [] path_mount+0x50f/0x1e50<br /> [] do_mount+0x107/0x130<br /> [] __se_sys_mount+0x1c5/0x2f0<br /> [] __x64_sys_mount+0xc7/0x160<br /> [] do_syscall_64+0x45/0x70<br /> unreferenced object 0xffff888114b54840 (size 32):<br /> comm "mount", pid 692, jiffies 4294838325 (age 34.288s)<br /> hex dump (first 32 bytes):<br /> c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u..............<br /> 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk.<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x584/0x880<br /> [] jffs2_sum_add_inode_mem+0x54/0x90<br /> [] jffs2_scan_medium.cold+0x4481/0x4794<br /> [...]<br /> unreferenced object 0xffff888114b57280 (size 32):<br /> comm "mount", pid 692, jiffies 4294838393 (age 34.357s)<br /> hex dump (first 32 bytes):<br /> 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l.............<br /> 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk.<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x584/0x880<br /> [] jffs2_sum_add_xattr_mem+0x54/0x90<br /> [] jffs2_scan_medium.cold+0x298c/0x4794<br /> [...]<br /> unreferenced object 0xffff8881116cd510 (size 16):<br /> comm "mount", pid 692, jiffies 4294838395 (age 34.355s)<br /> hex dump (first 16 bytes):<br /> 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k.<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x584/0x880<br /> [] jffs2_sum_add_xref_mem+0x54/0x90<br /> [] jffs2_scan_medium.cold+0x3a20/0x4794<br /> [...]<br /> --------------------------------------------<br /> <br /> Therefore, we should call jffs2_sum_reset_collected(s) on exit to<br /> release the memory added in s. In addition, a new tag "out_buf" is<br /> added to prevent the NULL pointer reference caused by s being NULL.<br /> (thanks to Zhang Yi for this analysis)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: fix memory leak in jffs2_do_mount_fs<br /> <br /> If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,<br /> we can observe the following kmemleak report:<br /> <br /> --------------------------------------------<br /> unreferenced object 0xffff88811b25a640 (size 64):<br /> comm "mount", pid 691, jiffies 4294957728 (age 71.952s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 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 /> [] kmem_cache_alloc_trace+0x584/0x880<br /> [] jffs2_sum_init+0x86/0x130<br /> [] jffs2_do_mount_fs+0x798/0xac0<br /> [] jffs2_do_fill_super+0x383/0xc30<br /> [] jffs2_fill_super+0x2ea/0x4c0<br /> [...]<br /> unreferenced object 0xffff88812c760000 (size 65536):<br /> comm "mount", pid 691, jiffies 4294957728 (age 71.952s)<br /> hex dump (first 32 bytes):<br /> bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................<br /> bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................<br /> backtrace:<br /> [] __kmalloc+0x6b9/0x910<br /> [] jffs2_sum_init+0xd7/0x130<br /> [] jffs2_do_mount_fs+0x798/0xac0<br /> [] jffs2_do_fill_super+0x383/0xc30<br /> [] jffs2_fill_super+0x2ea/0x4c0<br /> [...]<br /> --------------------------------------------<br /> <br /> This is because the resources allocated in jffs2_sum_init() are not<br /> released. Call jffs2_sum_exit() to release these resources to solve<br /> the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: Fix count check in rproc_coredump_write()<br /> <br /> Check count for 0, to avoid a potential underflow. Make the check the<br /> same as the one in rproc_recovery_write().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: prevent integer overflow on 32 bit systems<br /> <br /> On a 32 bit system, the "len * sizeof(*p)" operation can have an<br /> integer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix handlecache and multiuser<br /> <br /> In multiuser each individual user has their own tcon structure for the<br /> share and thus their own handle for a cached directory.<br /> When we umount such a share we much make sure to release the pinned down dentry<br /> for each such tcon and not just the master tcon.<br /> <br /> Otherwise we will get nasty warnings on umount that dentries are still in use:<br /> [ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still in use\<br /> (2) [unmount of cifs cifs]<br /> ...<br /> [ 3459.590492] Call Trace:<br /> [ 3459.590500] d_walk+0x61/0x2a0<br /> [ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0<br /> [ 3459.590526] shrink_dcache_for_umount+0x49/0x110<br /> [ 3459.590535] generic_shutdown_super+0x1a/0x110<br /> [ 3459.590542] kill_anon_super+0x14/0x30<br /> [ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs]<br /> [ 3459.590773] deactivate_locked_super+0x36/0xa0<br /> [ 3459.590782] cleanup_mnt+0x131/0x190<br /> [ 3459.590789] task_work_run+0x5c/0x90<br /> [ 3459.590798] exit_to_user_mode_loop+0x151/0x160<br /> [ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0<br /> [ 3459.590818] syscall_exit_to_user_mode+0x12/0x30<br /> [ 3459.590828] do_syscall_64+0x48/0x90<br /> [ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: prevent underflow in nfssvc_decode_writeargs()<br /> <br /> Smatch complains:<br /> <br /> fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()<br /> warn: no lower bound on &amp;#39;args-&gt;len&amp;#39;<br /> <br /> Change the type to unsigned to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: add missing boundary check in vm_access<br /> <br /> A missing bounds check in vm_access() can lead to an out-of-bounds read<br /> or write in the adjacent memory area, since the len attribute is not<br /> validated before the memcpy later in the function, potentially hitting:<br /> <br /> [ 183.637831] BUG: unable to handle page fault for address: ffffc90000c86000<br /> [ 183.637934] #PF: supervisor read access in kernel mode<br /> [ 183.637997] #PF: error_code(0x0000) - not-present page<br /> [ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0<br /> [ 183.638144] Oops: 0000 [#2] PREEMPT SMP NOPTI<br /> [ 183.638201] CPU: 3 PID: 1790 Comm: poc Tainted: G D 5.17.0-rc6-ci-drm-11296+ #1<br /> [ 183.638298] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319 05/30/2019<br /> [ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10<br /> [ 183.640213] RSP: 0018:ffffc90001763d48 EFLAGS: 00010246<br /> [ 183.641117] RAX: ffff888109c14000 RBX: ffff888111bece40 RCX: 0000000000000ffc<br /> [ 183.642029] RDX: 0000000000001000 RSI: ffffc90000c86000 RDI: ffff888109c14004<br /> [ 183.642946] RBP: 0000000000000ffc R08: 800000000000016b R09: 0000000000000000<br /> [ 183.643848] R10: ffffc90000c85000 R11: 0000000000000048 R12: 0000000000001000<br /> [ 183.644742] R13: ffff888111bed190 R14: ffff888109c14000 R15: 0000000000001000<br /> [ 183.645653] FS: 00007fe5ef807540(0000) GS:ffff88845b380000(0000) knlGS:0000000000000000<br /> [ 183.646570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 183.647481] CR2: ffffc90000c86000 CR3: 000000010ff02006 CR4: 00000000003706e0<br /> [ 183.648384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 183.649271] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 183.650142] Call Trace:<br /> [ 183.650988] <br /> [ 183.651793] vm_access+0x1f0/0x2a0 [i915]<br /> [ 183.652726] __access_remote_vm+0x224/0x380<br /> [ 183.653561] mem_rw.isra.0+0xf9/0x190<br /> [ 183.654402] vfs_read+0x9d/0x1b0<br /> [ 183.655238] ksys_read+0x63/0xe0<br /> [ 183.656065] do_syscall_64+0x38/0xc0<br /> [ 183.656882] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 183.657663] RIP: 0033:0x7fe5ef725142<br /> [ 183.659351] RSP: 002b:00007ffe1e81c7e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> [ 183.660227] RAX: ffffffffffffffda RBX: 0000557055dfb780 RCX: 00007fe5ef725142<br /> [ 183.661104] RDX: 0000000000001000 RSI: 00007ffe1e81d880 RDI: 0000000000000005<br /> [ 183.661972] RBP: 00007ffe1e81e890 R08: 0000000000000030 R09: 0000000000000046<br /> [ 183.662832] R10: 0000557055dfc2e0 R11: 0000000000000246 R12: 0000557055dfb1c0<br /> [ 183.663691] R13: 00007ffe1e81e980 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> Changes since v1:<br /> - Updated if condition with range_overflows_t [Chris Wilson]<br /> <br /> [mauld: tidy up the commit message and add Cc: stable]<br /> (cherry picked from commit 661412e301e2ca86799aa4f400d1cf0bd38c57c6)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: octeontx2 - remove CONFIG_DM_CRYPT check<br /> <br /> No issues were found while using the driver with dm-crypt enabled. So<br /> CONFIG_DM_CRYPT check in the driver can be removed.<br /> <br /> This also fixes the NULL pointer dereference in driver release if<br /> CONFIG_DM_CRYPT is enabled.<br /> <br /> ...<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> ...<br /> Call trace:<br /> crypto_unregister_alg+0x68/0xfc<br /> crypto_unregister_skciphers+0x44/0x60<br /> otx2_cpt_crypto_exit+0x100/0x1a0<br /> otx2_cptvf_remove+0xf8/0x200<br /> pci_device_remove+0x3c/0xd4<br /> __device_release_driver+0x188/0x234<br /> device_release_driver+0x2c/0x4c<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path<br /> <br /> This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that<br /> the CLM blob is released in the device remove path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exec: Force single empty string when argv is empty<br /> <br /> Quoting[1] Ariadne Conill:<br /> <br /> "In several other operating systems, it is a hard requirement that the<br /> second argument to execve(2) be the name of a program, thus prohibiting<br /> a scenario where argc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: domains: Fix sleep-in-atomic bug caused by genpd_debug_remove()<br /> <br /> When a genpd with GENPD_FLAG_IRQ_SAFE gets removed, the following<br /> sleep-in-atomic bug will be seen, as genpd_debug_remove() will be called<br /> with a spinlock being held.<br /> <br /> [ 0.029183] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1460<br /> [ 0.029204] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0<br /> [ 0.029219] preempt_count: 1, expected: 0<br /> [ 0.029230] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc4+ #489<br /> [ 0.029245] Hardware name: Thundercomm TurboX CM2290 (DT)<br /> [ 0.029256] Call trace:<br /> [ 0.029265] dump_backtrace.part.0+0xbc/0xd0<br /> [ 0.029285] show_stack+0x3c/0xa0<br /> [ 0.029298] dump_stack_lvl+0x7c/0xa0<br /> [ 0.029311] dump_stack+0x18/0x34<br /> [ 0.029323] __might_resched+0x10c/0x13c<br /> [ 0.029338] __might_sleep+0x4c/0x80<br /> [ 0.029351] down_read+0x24/0xd0<br /> [ 0.029363] lookup_one_len_unlocked+0x9c/0xcc<br /> [ 0.029379] lookup_positive_unlocked+0x10/0x50<br /> [ 0.029392] debugfs_lookup+0x68/0xac<br /> [ 0.029406] genpd_remove.part.0+0x12c/0x1b4<br /> [ 0.029419] of_genpd_remove_last+0xa8/0xd4<br /> [ 0.029434] psci_cpuidle_domain_probe+0x174/0x53c<br /> [ 0.029449] platform_probe+0x68/0xe0<br /> [ 0.029462] really_probe+0x190/0x430<br /> [ 0.029473] __driver_probe_device+0x90/0x18c<br /> [ 0.029485] driver_probe_device+0x40/0xe0<br /> [ 0.029497] __driver_attach+0xf4/0x1d0<br /> [ 0.029508] bus_for_each_dev+0x70/0xd0<br /> [ 0.029523] driver_attach+0x24/0x30<br /> [ 0.029534] bus_add_driver+0x164/0x22c<br /> [ 0.029545] driver_register+0x78/0x130<br /> [ 0.029556] __platform_driver_register+0x28/0x34<br /> [ 0.029569] psci_idle_init_domains+0x1c/0x28<br /> [ 0.029583] do_one_initcall+0x50/0x1b0<br /> [ 0.029595] kernel_init_freeable+0x214/0x280<br /> [ 0.029609] kernel_init+0x2c/0x13c<br /> [ 0.029622] ret_from_fork+0x10/0x20<br /> <br /> It doesn&amp;#39;t seem necessary to call genpd_debug_remove() with the lock, so<br /> move it out from locking to fix the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix rq-qos breakage from skipping rq_qos_done_bio()<br /> <br /> a647a524a467 ("block: don&amp;#39;t call rq_qos_ops-&gt;done_bio if the bio isn&amp;#39;t<br /> tracked") made bio_endio() skip rq_qos_done_bio() if BIO_TRACKED is not set.<br /> While this fixed a potential oops, it also broke blk-iocost by skipping the<br /> done_bio callback for merged bios.<br /> <br /> Before, whether a bio goes through rq_qos_throttle() or rq_qos_merge(),<br /> rq_qos_done_bio() would be called on the bio on completion with BIO_TRACKED<br /> distinguishing the former from the latter. rq_qos_done_bio() is not called<br /> for bios which wenth through rq_qos_merge(). This royally confuses<br /> blk-iocost as the merged bios never finish and are considered perpetually<br /> in-flight.<br /> <br /> One reliably reproducible failure mode is an intermediate cgroup geting<br /> stuck active preventing its children from being activated due to the<br /> leaf-only rule, leading to loss of control. The following is from<br /> resctl-bench protection scenario which emulates isolating a web server like<br /> workload from a memory bomb run on an iocost configuration which should<br /> yield a reasonable level of protection.<br /> <br /> # cat /sys/block/nvme2n1/device/model<br /> Samsung SSD 970 PRO 512GB<br /> # cat /sys/fs/cgroup/io.cost.model<br /> 259:0 ctrl=user model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025<br /> # cat /sys/fs/cgroup/io.cost.qos<br /> 259:0 enable=1 ctrl=user rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 min=60.00 max=100.00<br /> # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1<br /> ...<br /> Memory Hog Summary<br /> ==================<br /> <br /> IO Latency: R p50=242u:336u/2.5m p90=794u:1.4m/7.5m p99=2.7m:8.0m/62.5m max=8.0m:36.4m/350m<br /> W p50=221u:323u/1.5m p90=709u:1.2m/5.5m p99=1.5m:2.5m/9.5m max=6.9m:35.9m/350m<br /> <br /> Isolation and Request Latency Impact Distributions:<br /> <br /> min p01 p05 p10 p25 p50 p75 p90 p95 p99 max mean stdev<br /> isol% 15.90 15.90 15.90 40.05 57.24 59.07 60.01 74.63 74.63 90.35 90.35 58.12 15.82<br /> lat-imp% 0 0 0 0 0 4.55 14.68 15.54 233.5 548.1 548.1 53.88 143.6<br /> <br /> Result: isol=58.12:15.82% lat_imp=53.88%:143.6 work_csv=100.0% missing=3.96%<br /> <br /> The isolation result of 58.12% is close to what this device would show<br /> without any IO control.<br /> <br /> Fix it by introducing a new flag BIO_QOS_MERGED to mark merged bios and<br /> calling rq_qos_done_bio() on them too. For consistency and clarity, rename<br /> BIO_TRACKED to BIO_QOS_THROTTLED. The flag checks are moved into<br /> rq_qos_done_bio() so that it&amp;#39;s next to the code paths that set the flags.<br /> <br /> With the patch applied, the above same benchmark shows:<br /> <br /> # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1<br /> ...<br /> Memory Hog Summary<br /> ==================<br /> <br /> IO Latency: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m max=11.1m:36.0m/350m<br /> W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m max=7.9m:5.9m/26.5m<br /> <br /> Isolation and Request Latency Impact Distributions:<br /> <br /> min p01 p05 p10 p25 p50 p75 p90 p95 p99 max mean stdev<br /> isol% 84.91 84.91 89.51 90.73 92.31 94.49 96.36 98.04 98.71 100.0 100.0 94.42 2.81<br /> lat-imp% 0 0 0 0 0 2.81 5.73 11.11 13.92 17.53 22.61 4.10 4.68<br /> <br /> Result: isol=94.42:2.81% lat_imp=4.10%:4.68 work_csv=58.34% missing=0%