Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds<br /> <br /> Presently ima_get_kexec_buffer() doesn&amp;#39;t check if the previous kernel&amp;#39;s<br /> ima-kexec-buffer lies outside the addressable memory range. This can result<br /> in a kernel panic if the new kernel is booted with &amp;#39;mem=X&amp;#39; arg and the<br /> ima-kexec-buffer was allocated beyond that range by the previous kernel.<br /> The panic is usually of the form below:<br /> <br /> $ sudo kexec --initrd initrd vmlinux --append=&amp;#39;mem=16G&amp;#39;<br /> <br /> <br /> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000<br /> Faulting instruction address: 0xc000000000837974<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> <br /> NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0<br /> LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160<br /> Call Trace:<br /> [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160<br /> [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108<br /> [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120<br /> [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0<br /> [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec<br /> [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0<br /> [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64<br /> Instruction dump:<br /> f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330<br /> 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Fix this issue by checking returned PFN range of previous kernel&amp;#39;s<br /> ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.

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 /> usb: ohci-nxp: Fix refcount leak in ohci_hcd_nxp_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: fix random warning message when driver load<br /> <br /> Warning log:<br /> [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code!<br /> [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20<br /> [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT)<br /> [ 4.163155] Call trace:<br /> [ 4.165600] dump_backtrace+0x0/0x1b0<br /> [ 4.169286] show_stack+0x18/0x68<br /> [ 4.172611] dump_stack_lvl+0x68/0x84<br /> [ 4.176286] dump_stack+0x18/0x34<br /> [ 4.179613] kmalloc_fix_flags+0x60/0x88<br /> [ 4.183550] new_slab+0x334/0x370<br /> [ 4.186878] ___slab_alloc.part.108+0x4d4/0x748<br /> [ 4.191419] __slab_alloc.isra.109+0x30/0x78<br /> [ 4.195702] kmem_cache_alloc+0x40c/0x420<br /> [ 4.199725] dma_pool_alloc+0xac/0x1f8<br /> [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0<br /> <br /> pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)<br /> {<br /> ...<br /> page = kmalloc(sizeof(*page), mem_flags);<br /> page-&gt;vaddr = dma_alloc_coherent(pool-&gt;dev, pool-&gt;allocation,<br /> &amp;page-&gt;dma, mem_flags);<br /> ...<br /> }<br /> <br /> kmalloc was called with mem_flags, which is passed down in<br /> cdns3_allocate_trb_pool() and have GFP_DMA32 flags.<br /> kmall_fix_flags() report warning.<br /> <br /> GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle<br /> DMA memory region correctly by pool-&gt;dev. GFP_DMA32 can be removed<br /> safely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: parsers: ofpart: Fix refcount leak in bcm4908_partitions_fw_offset<br /> <br /> of_find_node_by_path() returns a node pointer with refcount incremented,<br /> we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: partitions: Fix refcount leak in parse_redboot_of<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: microchip: Fix refcount leak in mc_pcie_init_irq_domains()<br /> <br /> of_get_next_child() returns a node pointer with refcount incremented, so we<br /> should use of_node_put() on it when we don&amp;#39;t need it anymore.<br /> <br /> mc_pcie_init_irq_domains() only calls of_node_put() in the normal path,<br /> missing it in some error paths. Add missing of_node_put() to avoid<br /> refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: cp2112: prevent a buffer overflow in cp2112_xfer()<br /> <br /> Smatch warnings:<br /> drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy()<br /> &amp;#39;data-&gt;block[1]&amp;#39; too small (33 vs 255)<br /> drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() &amp;#39;buf&amp;#39; too<br /> small (64 vs 255)<br /> <br /> The &amp;#39;read_length&amp;#39; variable is provided by &amp;#39;data-&gt;block[0]&amp;#39; which comes<br /> from user and it(read_length) can take a value between 0-255. Add an<br /> upper bound to &amp;#39;read_length&amp;#39; variable to prevent a buffer overflow in<br /> memcpy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: mediatek-gen3: Fix refcount leak in mtk_pcie_init_irq_domains()<br /> <br /> of_get_child_by_name() returns a node pointer with refcount incremented, so<br /> we should use of_node_put() on it when we don&amp;#39;t need it anymore.<br /> <br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe<br /> <br /> of_find_compatible_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: fix potential deadlock in __driver_attach<br /> <br /> In __driver_attach function, There are also AA deadlock problem,<br /> like the commit b232b02bf3c2 ("driver core: fix deadlock in<br /> __device_attach").<br /> <br /> stack like commit b232b02bf3c2 ("driver core: fix deadlock in<br /> __device_attach").<br /> list below:<br /> In __driver_attach function, The lock holding logic is as follows:<br /> ...<br /> __driver_attach<br /> if (driver_allows_async_probing(drv))<br /> device_lock(dev) // get lock dev<br /> async_schedule_dev(__driver_attach_async_helper, dev); // func<br /> async_schedule_node<br /> async_schedule_node_domain(func)<br /> entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);<br /> /* when fail or work limit, sync to execute func, but<br /> __driver_attach_async_helper will get lock dev as<br /> will, which will lead to A-A deadlock. */<br /> if (!entry || atomic_read(&amp;entry_count) &gt; MAX_WORK) {<br /> func;<br /> else<br /> queue_work_node(node, system_unbound_wq, &amp;entry-&gt;work)<br /> device_unlock(dev)<br /> <br /> As above show, when it is allowed to do async probes, because of<br /> out of memory or work limit, async work is not be allowed, to do<br /> sync execute instead. it will lead to A-A deadlock because of<br /> __driver_attach_async_helper getting lock dev.<br /> <br /> Reproduce:<br /> and it can be reproduce by make the condition<br /> (if (!entry || atomic_read(&amp;entry_count) &gt; MAX_WORK)) untenable, like<br /> below:<br /> <br /> [ 370.785650] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables<br /> this message.<br /> [ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:<br /> 0 flags:0x00004000<br /> [ 370.788865] Call Trace:<br /> [ 370.789374] <br /> [ 370.789841] __schedule+0x482/0x1050<br /> [ 370.790613] schedule+0x92/0x1a0<br /> [ 370.791290] schedule_preempt_disabled+0x2c/0x50<br /> [ 370.792256] __mutex_lock.isra.0+0x757/0xec0<br /> [ 370.793158] __mutex_lock_slowpath+0x1f/0x30<br /> [ 370.794079] mutex_lock+0x50/0x60<br /> [ 370.794795] __device_driver_lock+0x2f/0x70<br /> [ 370.795677] ? driver_probe_device+0xd0/0xd0<br /> [ 370.796576] __driver_attach_async_helper+0x1d/0xd0<br /> [ 370.797318] ? driver_probe_device+0xd0/0xd0<br /> [ 370.797957] async_schedule_node_domain+0xa5/0xc0<br /> [ 370.798652] async_schedule_node+0x19/0x30<br /> [ 370.799243] __driver_attach+0x246/0x290<br /> [ 370.799828] ? driver_allows_async_probing+0xa0/0xa0<br /> [ 370.800548] bus_for_each_dev+0x9d/0x130<br /> [ 370.801132] driver_attach+0x22/0x30<br /> [ 370.801666] bus_add_driver+0x290/0x340<br /> [ 370.802246] driver_register+0x88/0x140<br /> [ 370.802817] ? virtio_scsi_init+0x116/0x116<br /> [ 370.803425] scsi_register_driver+0x1a/0x30<br /> [ 370.804057] init_sd+0x184/0x226<br /> [ 370.804533] do_one_initcall+0x71/0x3a0<br /> [ 370.805107] kernel_init_freeable+0x39a/0x43a<br /> [ 370.805759] ? rest_init+0x150/0x150<br /> [ 370.806283] kernel_init+0x26/0x230<br /> [ 370.806799] ret_from_fork+0x1f/0x30<br /> <br /> To fix the deadlock, move the async_schedule_dev outside device_lock,<br /> as we can see, in async_schedule_node_domain, the parameter of<br /> queue_work_node is system_unbound_wq, so it can accept concurrent<br /> operations. which will also not change the code logic, and will<br /> not lead to deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernfs: fix potential NULL dereference in __kernfs_remove<br /> <br /> When lockdep is enabled, lockdep_assert_held_write would<br /> cause potential NULL pointer dereference.<br /> <br /> Fix the following smatch warnings:<br /> <br /> fs/kernfs/dir.c:1353 __kernfs_remove() warn: variable dereferenced before check &amp;#39;kn&amp;#39; (see line 1346)