Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: coda: Add check for dcoda_iram_alloc<br /> <br /> As the coda_iram_alloc may return NULL pointer,<br /> it should be better to check the return value<br /> in order to avoid NULL poineter dereference,<br /> same as the others.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed<br /> <br /> If some items in nsim_dev_resources_register() fail, memory leak will<br /> occur. The following is the memory leak information.<br /> <br /> unreferenced object 0xffff888074c02600 (size 128):<br /> comm "echo", pid 8159, jiffies 4294945184 (age 493.530s)<br /> hex dump (first 32 bytes):<br /> 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G..............<br /> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br /> backtrace:<br /> [] kmalloc_trace+0x22/0x60<br /> [] devl_resource_register+0x144/0x4e0<br /> [] nsim_drv_probe+0x37a/0x1260<br /> [] really_probe+0x20b/0xb10<br /> [] __driver_probe_device+0x1b3/0x4a0<br /> [] driver_probe_device+0x49/0x140<br /> [] __device_attach_driver+0x18c/0x2a0<br /> [] bus_for_each_drv+0x151/0x1d0<br /> [] __device_attach+0x1c9/0x4e0<br /> [] bus_probe_device+0x1d5/0x280<br /> [] device_add+0xae0/0x1cb0<br /> [] new_device_store+0x3b6/0x5f0<br /> [] bus_attr_store+0x72/0xa0<br /> [] sysfs_kf_write+0x106/0x160<br /> [] kernfs_fop_write_iter+0x3a8/0x5a0<br /> [] vfs_write+0x8f0/0xc80

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-core: Fix double free in dvb_register_device()<br /> <br /> In function dvb_register_device() -&gt; dvb_register_media_device() -&gt;<br /> dvb_create_media_entity(), dvb-&gt;entity is allocated and initialized. If<br /> the initialization fails, it frees the dvb-&gt;entity, and return an error<br /> code. The caller takes the error code and handles the error by calling<br /> dvb_media_device_free(), which unregisters the entity and frees the<br /> field again if it is not NULL. As dvb-&gt;entity may not NULLed in<br /> dvb_create_media_entity() when the allocation of dvbdev-&gt;pad fails, a<br /> double free may occur. This may also cause an Use After free in<br /> media_device_unregister_entity().<br /> <br /> Fix this by storing NULL to dvb-&gt;entity when it is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Validate data run offset<br /> <br /> This adds sanity checks for data run offset. We should make sure data<br /> run offset is legit before trying to unpack them, otherwise we may<br /> encounter use-after-free or some unexpected memory access behaviors.<br /> <br /> [ 82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570<br /> [ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240<br /> [ 82.941670]<br /> [ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15<br /> [ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 82.943720] Call Trace:<br /> [ 82.944204] <br /> [ 82.944471] dump_stack_lvl+0x49/0x63<br /> [ 82.944908] print_report.cold+0xf5/0x67b<br /> [ 82.945141] ? __wait_on_bit+0x106/0x120<br /> [ 82.945750] ? run_unpack+0x2e3/0x570<br /> [ 82.946626] kasan_report+0xa7/0x120<br /> [ 82.947046] ? run_unpack+0x2e3/0x570<br /> [ 82.947280] __asan_load1+0x51/0x60<br /> [ 82.947483] run_unpack+0x2e3/0x570<br /> [ 82.947709] ? memcpy+0x4e/0x70<br /> [ 82.947927] ? run_pack+0x7a0/0x7a0<br /> [ 82.948158] run_unpack_ex+0xad/0x3f0<br /> [ 82.948399] ? mi_enum_attr+0x14a/0x200<br /> [ 82.948717] ? run_unpack+0x570/0x570<br /> [ 82.949072] ? ni_enum_attr_ex+0x1b2/0x1c0<br /> [ 82.949332] ? ni_fname_type.part.0+0xd0/0xd0<br /> [ 82.949611] ? mi_read+0x262/0x2c0<br /> [ 82.949970] ? ntfs_cmp_names_cpu+0x125/0x180<br /> [ 82.950249] ntfs_iget5+0x632/0x1870<br /> [ 82.950621] ? ntfs_get_block_bmap+0x70/0x70<br /> [ 82.951192] ? evict+0x223/0x280<br /> [ 82.951525] ? iput.part.0+0x286/0x320<br /> [ 82.951969] ntfs_fill_super+0x1321/0x1e20<br /> [ 82.952436] ? put_ntfs+0x1d0/0x1d0<br /> [ 82.952822] ? vsprintf+0x20/0x20<br /> [ 82.953188] ? mutex_unlock+0x81/0xd0<br /> [ 82.953379] ? set_blocksize+0x95/0x150<br /> [ 82.954001] get_tree_bdev+0x232/0x370<br /> [ 82.954438] ? put_ntfs+0x1d0/0x1d0<br /> [ 82.954700] ntfs_fs_get_tree+0x15/0x20<br /> [ 82.955049] vfs_get_tree+0x4c/0x130<br /> [ 82.955292] path_mount+0x645/0xfd0<br /> [ 82.955615] ? putname+0x80/0xa0<br /> [ 82.955955] ? finish_automount+0x2e0/0x2e0<br /> [ 82.956310] ? kmem_cache_free+0x110/0x390<br /> [ 82.956723] ? putname+0x80/0xa0<br /> [ 82.957023] do_mount+0xd6/0xf0<br /> [ 82.957411] ? path_mount+0xfd0/0xfd0<br /> [ 82.957638] ? __kasan_check_write+0x14/0x20<br /> [ 82.957948] __x64_sys_mount+0xca/0x110<br /> [ 82.958310] do_syscall_64+0x3b/0x90<br /> [ 82.958719] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 82.959341] RIP: 0033:0x7fd0d1ce948a<br /> [ 82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5<br /> [ 82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a<br /> [ 82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0<br /> [ 82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020<br /> [ 82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0<br /> [ 82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: only clone bio if we have a backing device<br /> <br /> Commit c347a787e34cb (drbd: set -&gt;bi_bdev in drbd_req_new) moved a<br /> bio_set_dev call (which has since been removed) to "earlier", from<br /> drbd_request_prepare to drbd_req_new.<br /> <br /> The problem is that this accesses device-&gt;ldev-&gt;backing_bdev, which is<br /> not NULL-checked at this point. When we don&amp;#39;t have an ldev (i.e. when<br /> the DRBD device is diskless), this leads to a null pointer deref.<br /> <br /> So, only allocate the private_bio if we actually have a disk. This is<br /> also a small optimization, since we don&amp;#39;t clone the bio to only to<br /> immediately free it again in the diskless case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Fix pci device refcount leak in ppr_notifier()<br /> <br /> As comment of pci_get_domain_bus_and_slot() says, it returns<br /> a pci device with refcount increment, when finish using it,<br /> the caller must decrement the reference count by calling<br /> pci_dev_put(). So call it before returning from ppr_notifier()<br /> to avoid refcount leak.

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 /> dm cache: Fix UAF in destroy()<br /> <br /> Dm_cache also has the same UAF problem when dm_resume()<br /> and dm_destroy() are concurrent.<br /> <br /> Therefore, cancelling timer again in destroy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: alx: take rtnl_lock on resume<br /> <br /> Zbynek reports that alx trips an rtnl assertion on resume:<br /> <br /> RTNL: assertion failed at net/core/dev.c (2891)<br /> RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0<br /> Call Trace:<br /> <br /> __alx_open+0x230/0x570 [alx]<br /> alx_resume+0x54/0x80 [alx]<br /> ? pci_legacy_resume+0x80/0x80<br /> dpm_run_callback+0x4a/0x150<br /> device_resume+0x8b/0x190<br /> async_resume+0x19/0x30<br /> async_run_entry_fn+0x30/0x130<br /> process_one_work+0x1e5/0x3b0<br /> <br /> indeed the driver does not hold rtnl_lock during its internal close<br /> and re-open functions during suspend/resume. Note that this is not<br /> a huge bug as the driver implements its own locking, and does not<br /> implement changing the number of queues, but we need to silence<br /> the splat.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_misc: fix shift-out-of-bounds in check_special_flags<br /> <br /> UBSAN reported a shift-out-of-bounds warning:<br /> <br /> left shift of 1 by 31 places cannot be represented in type &amp;#39;int&amp;#39;<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106<br /> ubsan_epilogue+0xa/0x44 lib/ubsan.c:151<br /> __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322<br /> check_special_flags fs/binfmt_misc.c:241 [inline]<br /> create_entry fs/binfmt_misc.c:456 [inline]<br /> bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654<br /> vfs_write+0x11e/0x580 fs/read_write.c:582<br /> ksys_write+0xcf/0x120 fs/read_write.c:637<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x4194e1<br /> <br /> Since the type of Node&amp;#39;s flags is unsigned long, we should define these<br /> macros with same type too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix use-after-free on probe deferral<br /> <br /> The bridge counter was never reset when tearing down the DRM device so<br /> that stale pointers to deallocated structures would be accessed on the<br /> next tear down (e.g. after a second late bind deferral).<br /> <br /> Given enough bridges and a few probe deferrals this could currently also<br /> lead to data beyond the bridge array being corrupted.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502665/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix crash when I/O abort times out<br /> <br /> While performing CPU hotplug, a crash with the following stack was seen:<br /> <br /> Call Trace:<br /> qla24xx_process_response_queue+0x42a/0x970 [qla2xxx]<br /> qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx]<br /> qla_nvme_post_cmd+0x166/0x240 [qla2xxx]<br /> nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc]<br /> blk_mq_dispatch_rq_list+0x17b/0x610<br /> __blk_mq_sched_dispatch_requests+0xb0/0x140<br /> blk_mq_sched_dispatch_requests+0x30/0x60<br /> __blk_mq_run_hw_queue+0x35/0x90<br /> __blk_mq_delay_run_hw_queue+0x161/0x180<br /> blk_execute_rq+0xbe/0x160<br /> __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core]<br /> nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics]<br /> nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc]<br /> nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc]<br /> process_one_work+0x1e8/0x3c0<br /> <br /> On abort timeout, completion was called without checking if the I/O was<br /> already completed.<br /> <br /> Verify that I/O and abort request are indeed outstanding before attempting<br /> completion.