Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: fix NULL pointer dereference<br /> <br /> Commit 71f642833284 ("ACPI: utils: Fix reference counting in<br /> for_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointer<br /> that was possibly NULL. That fails miserably, because that helper<br /> inline function is not set up to handle that case.<br /> <br /> Just make acpi_dev_put() silently accept a NULL pointer, rather than<br /> calling down to put_device() with an invalid offset off that NULL<br /> pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: wcd934x: Fix shift-out-of-bounds error<br /> <br /> bit-mask for pins 0 to 4 is BIT(0) to BIT(4) however we ended up with BIT(n - 1)<br /> which is not right, and this was caught by below usban check<br /> <br /> UBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: core: Fix Null-point-dereference in fmt_single_name()<br /> <br /> Check the return value of devm_kstrdup() in case of<br /> Null-point-dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA: Verify port when creating flow rule<br /> <br /> Validate port value provided by the user and with that remove no longer<br /> needed validation by the driver. The missing check in the mlx5_ib driver<br /> could cause to the below oops.<br /> <br /> Call trace:<br /> _create_flow_rule+0x2d4/0xf28 [mlx5_ib]<br /> mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]<br /> ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]<br /> ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]<br /> ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]<br /> ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]<br /> do_vfs_ioctl+0xd0/0xaf0<br /> ksys_ioctl+0x84/0xb4<br /> __arm64_sys_ioctl+0x28/0xc4<br /> el0_svc_common.constprop.3+0xa4/0x254<br /> el0_svc_handler+0x84/0xa0<br /> el0_svc+0x10/0x26c<br /> Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/ipoib: Fix warning caused by destroying non-initial netns<br /> <br /> After the commit 5ce2dced8e95 ("RDMA/ipoib: Set rtnl_link_ops for ipoib<br /> interfaces"), if the IPoIB device is moved to non-initial netns,<br /> destroying that netns lets the device vanish instead of moving it back to<br /> the initial netns, This is happening because default_device_exit() skips<br /> the interfaces due to having rtnl_link_ops set.<br /> <br /> Steps to reporoduce:<br /> ip netns add foo<br /> ip link set mlx5_ib0 netns foo<br /> ip netns delete foo<br /> <br /> WARNING: CPU: 1 PID: 704 at net/core/dev.c:11435 netdev_exit+0x3f/0x50<br /> Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT<br /> nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack<br /> nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d<br /> fuse<br /> CPU: 1 PID: 704 Comm: kworker/u64:3 Tainted: G S W 5.13.0-rc1+ #1<br /> Hardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.5 04/11/2016<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:netdev_exit+0x3f/0x50<br /> Code: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48<br /> 8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 0b 5b<br /> c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00<br /> RSP: 0018:ffffb297079d7e08 EFLAGS: 00010206<br /> RAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX: 000000008010000d<br /> RDX: 000000008010000e RSI: 000000008010000d RDI: ffff8eb440042c00<br /> RBP: ffffb297079d7e48 R08: 0000000000000001 R09: ffffffff9fdeac00<br /> R10: ffff8eb5003be000 R11: 0000000000000001 R12: ffffffffa1545620<br /> R13: ffffffffa1545628 R14: 0000000000000000 R15: ffffffffa1543b20<br /> FS: 0000000000000000(0000) GS:ffff8ed37fa00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ops_exit_list.isra.9+0x36/0x70<br /> cleanup_net+0x234/0x390<br /> process_one_work+0x1cb/0x360<br /> ? process_one_work+0x360/0x360<br /> worker_thread+0x30/0x370<br /> ? process_one_work+0x360/0x360<br /> kthread+0x116/0x130<br /> ? kthread_park+0x80/0x80<br /> ret_from_fork+0x22/0x30<br /> <br /> To avoid the above warning and later on the kernel panic that could happen<br /> on shutdown due to a NULL pointer dereference, make sure to set the<br /> netns_refund flag that was introduced by commit 3a5ca857079e ("can: dev:<br /> Move device back to init netns on owning netns delete") to properly<br /> restore the IPoIB interfaces to the initial netns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: fix various gadget panics on 10gbps cabling<br /> <br /> usb_assign_descriptors() is called with 5 parameters,<br /> the last 4 of which are the usb_descriptor_header for:<br /> full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),<br /> high-speed (USB2.0 - 480Mbps),<br /> super-speed (USB3.0 - 5Gbps),<br /> super-speed-plus (USB3.1 - 10Gbps).<br /> <br /> The differences between full/high/super-speed descriptors are usually<br /> substantial (due to changes in the maximum usb block size from 64 to 512<br /> to 1024 bytes and other differences in the specs), while the difference<br /> between 5 and 10Gbps descriptors may be as little as nothing<br /> (in many cases the same tuning is simply good enough).<br /> <br /> However if a gadget driver calls usb_assign_descriptors() with<br /> a NULL descriptor for super-speed-plus and is then used on a max 10gbps<br /> configuration, the kernel will crash with a null pointer dereference,<br /> when a 10gbps capable device port + cable + host port combination shows up.<br /> (This wouldn&amp;#39;t happen if the gadget max-speed was set to 5gbps, but<br /> it of course defaults to the maximum, and there&amp;#39;s no real reason to<br /> artificially limit it)<br /> <br /> The fix is to simply use the 5gbps descriptor as the 10gbps descriptor,<br /> if a 10gbps descriptor wasn&amp;#39;t provided.<br /> <br /> Obviously this won&amp;#39;t fix the problem if the 5gbps descriptor is also<br /> NULL, but such cases can&amp;#39;t be so trivially solved (and any such gadgets<br /> are unlikely to be used with USB3 ports any way).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: cancel vdm and state machine hrtimer when unregister tcpm port<br /> <br /> A pending hrtimer may expire after the kthread_worker of tcpm port<br /> is destroyed, see below kernel dump when do module unload, fix it<br /> by cancel the 2 hrtimers.<br /> <br /> [ 111.517018] Unable to handle kernel paging request at virtual address ffff8000118cb880<br /> [ 111.518786] blk_update_request: I/O error, dev sda, sector 60061185 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0<br /> [ 111.526594] Mem abort info:<br /> [ 111.526597] ESR = 0x96000047<br /> [ 111.526600] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 111.526604] SET = 0, FnV = 0<br /> [ 111.526607] EA = 0, S1PTW = 0<br /> [ 111.526610] Data abort info:<br /> [ 111.526612] ISV = 0, ISS = 0x00000047<br /> [ 111.526615] CM = 0, WnR = 1<br /> [ 111.526619] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041d75000<br /> [ 111.526623] [ffff8000118cb880] pgd=10000001bffff003, p4d=10000001bffff003, pud=10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000<br /> [ 111.526642] Internal error: Oops: 96000047 [#1] PREEMPT SMP<br /> [ 111.526647] Modules linked in: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [last unloaded: tcpci]<br /> [ 111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36<br /> [ 111.526670] Hardware name: NXP i.MX8MPlus EVK board (DT)<br /> [ 111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--)<br /> [ 111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390<br /> [ 111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4<br /> [ 111.526703] sp : ffff800010003e20<br /> [ 111.526706] x29: ffff800010003e20 x28: ffff00017f380180<br /> [ 111.537156] buffer_io_error: 6 callbacks suppressed<br /> [ 111.537162] Buffer I/O error on dev sda1, logical block 60040704, async page read<br /> [ 111.539932] x27: ffff00017f3801c0<br /> [ 111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 0000000000000001<br /> [ 111.543025] blk_update_request: I/O error, dev sda, sector 60061186 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 0<br /> [ 111.548304]<br /> [ 111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180<br /> [ 111.551374] Buffer I/O error on dev sda1, logical block 60040705, async page read<br /> [ 111.554499]<br /> [ 111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000<br /> [ 111.557391] Buffer I/O error on dev sda1, logical block 60040706, async page read<br /> [ 111.561218]<br /> [ 111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 111.564205] Buffer I/O error on dev sda1, logical block 60040707, async page read<br /> [ 111.570887] x14: 00000000000000f5 x13: 0000000000000001 x12: 0000000000000040<br /> [ 111.570902] x11: ffff0000c05ac6d8<br /> [ 111.583420] Buffer I/O error on dev sda1, logical block 60040708, async page read<br /> [ 111.588978] x10: 0000000000000000 x9 : 0000000000040000<br /> [ 111.588988] x8 : 0000000000000000<br /> [ 111.597173] Buffer I/O error on dev sda1, logical block 60040709, async page read<br /> [ 111.605766] x7 : ffff00017f384880 x6 : ffff8000118cb880<br /> [ 111.605777] x5 : ffff00017f384880<br /> [ 111.611094] Buffer I/O error on dev sda1, logical block 60040710, async page read<br /> [ 111.617086] x4 : 0000000000000000 x3 : ffff0000c2a9f184<br /> [ 111.617096] x2 : ffff8000118cb880<br /> [ 111.622242] Buffer I/O error on dev sda1, logical block 60040711, async page read<br /> [ 111.626927] x1 : ffff8000118cb880 x0 : ffff00017f384888<br /> [ 111.626938] Call trace:<br /> [ 111.626942] queued_spin_lock_slowpath+0x1a0/0x390<br /> [ 111.795809] kthread_queue_work+0x30/0xc0<br /> [ 111.799828] state_machine_timer_handler+0x20/0x30<br /> [ 111.804624] __hrtimer_run_queues+0x140/0x1e0<br /> [ 111.808990] hrtimer_interrupt+0xec/0x2c0<br /> [ 111.813004] arch_timer_handler_phys+0x38/0x50<br /> [ 111.817456] handle_percpu_devid_irq+0x88/0x150<br /> [ 111.821991] __handle_domain_irq+0x80/0xe0<br /> [ 111.826093] gic_handle_irq+0xc0/0x140<br /> [ 111.829848] el1_irq+0xbc/0x154<br /> [ 111.832991] arch_cpu_idle+0x1c/0x2c<br /> [ 111.836572] default_idle_call+0x24/0x6c<br /> [ 111.840497] do_idle+0x238/0x2ac<br /> [ 1<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: ep0: fix NULL pointer exception<br /> <br /> There is no validation of the index from dwc3_wIndex_to_dep() and we might<br /> be referring a non-existing ep and trigger a NULL pointer exception. In<br /> certain configurations we might use fewer eps and the index might wrongly<br /> indicate a larger ep index than existing.<br /> <br /> By adding this validation from the patch we can actually report a wrong<br /> index back to the caller.<br /> <br /> In our usecase we are using a composite device on an older kernel, but<br /> upstream might use this fix also. Unfortunately, I cannot describe the<br /> hardware for others to reproduce the issue as it is a proprietary<br /> implementation.<br /> <br /> [ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4<br /> [ 82.966891] Mem abort info:<br /> [ 82.969663] ESR = 0x96000006<br /> [ 82.972703] Exception class = DABT (current EL), IL = 32 bits<br /> [ 82.978603] SET = 0, FnV = 0<br /> [ 82.981642] EA = 0, S1PTW = 0<br /> [ 82.984765] Data abort info:<br /> [ 82.987631] ISV = 0, ISS = 0x00000006<br /> [ 82.991449] CM = 0, WnR = 0<br /> [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc<br /> [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000<br /> [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP<br /> [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)<br /> [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1<br /> [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)<br /> [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c<br /> [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94<br /> <br /> ...<br /> <br /> [ 83.141788] Call trace:<br /> [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c<br /> [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94<br /> [ 83.181546] ---[ end trace aac6b5267d84c32f ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: fix various gadgets null ptr deref on 10gbps cabling.<br /> <br /> This avoids a null pointer dereference in<br /> f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}<br /> by simply reusing the 5gbps config for 10gbps.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler<br /> <br /> Patch fixes the following critical issue caused by deadlock which has been<br /> detected during testing NCM class:<br /> <br /> smp: csd: Detected non-responsive CSD lock (#1) on CPU#0<br /> smp: csd: CSD lock (#1) unresponsive.<br /> ....<br /> RIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0<br /> RSP: 0018:ffffbc494011cde0 EFLAGS: 00000002<br /> RAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658<br /> RBP: ffffbc494011cde0 R08: 0000000000000001 R09: 0000000000000000<br /> R10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658<br /> R13: ffff9ee8116b4670 R14: 0000000000000246 R15: ffff9ee8116b4658<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> do_raw_spin_lock+0xc0/0xd0<br /> _raw_spin_lock_irqsave+0x95/0xa0<br /> cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci]<br /> usb_ep_queue+0x35/0x110<br /> eth_start_xmit+0x220/0x3d0 [u_ether]<br /> ncm_tx_timeout+0x34/0x40 [usb_f_ncm]<br /> ? ncm_free_inst+0x50/0x50 [usb_f_ncm]<br /> __hrtimer_run_queues+0xac/0x440<br /> hrtimer_run_softirq+0x8c/0xb0<br /> __do_softirq+0xcf/0x428<br /> asm_call_irq_on_stack+0x12/0x20<br /> <br /> do_softirq_own_stack+0x61/0x70<br /> irq_exit_rcu+0xc1/0xd0<br /> sysvec_apic_timer_interrupt+0x52/0xb0<br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> RIP: 0010:do_raw_spin_trylock+0x18/0x40<br /> RSP: 0018:ffffbc494138bda8 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9ee8116b4658<br /> RBP: ffffbc494138bda8 R08: 0000000000000001 R09: 0000000000000000<br /> R10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658<br /> R13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000<br /> _raw_spin_lock+0x3d/0x70<br /> ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]<br /> cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]<br /> ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci]<br /> ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci]<br /> ? irq_thread+0xa0/0x1c0<br /> irq_thread_fn+0x28/0x60<br /> irq_thread+0x105/0x1c0<br /> ? __kthread_parkme+0x42/0x90<br /> ? irq_forced_thread_fn+0x90/0x90<br /> ? wake_threads_waitq+0x30/0x30<br /> ? irq_thread_check_affinity+0xe0/0xe0<br /> kthread+0x12a/0x160<br /> ? kthread_park+0x90/0x90<br /> ret_from_fork+0x22/0x30<br /> <br /> The root cause of issue is spin_lock/spin_unlock instruction instead<br /> spin_lock_irqsave/spin_lock_irqrestore in cdnsp_thread_irq_handler<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc-&gt;gadget is NULL<br /> <br /> There exists a possible scenario in which dwc3_gadget_init() can fail:<br /> during during host -&gt; peripheral mode switch in dwc3_set_mode(), and<br /> a pending gadget driver fails to bind. Then, if the DRD undergoes<br /> another mode switch from peripheral-&gt;host the resulting<br /> dwc3_gadget_exit() will attempt to reference an invalid and dangling<br /> dwc-&gt;gadget pointer as well as call dma_free_coherent() on unmapped<br /> DMA pointers.<br /> <br /> The exact scenario can be reproduced as follows:<br /> - Start DWC3 in peripheral mode<br /> - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)<br /> - Run FunctionFS userspace application (open EPs, write descriptors, etc)<br /> - Bind gadget driver to DWC3&amp;#39;s UDC<br /> - Switch DWC3 to host mode<br /> =&gt; dwc3_gadget_exit() is called. usb_del_gadget() will put the<br /> ConfigFS driver instance on the gadget_driver_pending_list<br /> - Stop FunctionFS application (closes the ep files)<br /> - Switch DWC3 to peripheral mode<br /> =&gt; dwc3_gadget_init() fails as usb_add_gadget() calls<br /> check_pending_gadget_drivers() and attempts to rebind the UDC<br /> to the ConfigFS gadget but fails with -19 (-ENODEV) because the<br /> FFS instance is not in FFS_ACTIVE state (userspace has not<br /> re-opened and written the descriptors yet, i.e. desc_ready!=0).<br /> - Switch DWC3 back to host mode<br /> =&gt; dwc3_gadget_exit() is called again, but this time dwc-&gt;gadget<br /> is invalid.<br /> <br /> Although it can be argued that userspace should take responsibility<br /> for ensuring that the FunctionFS application be ready prior to<br /> allowing the composite driver bind to the UDC, failure to do so<br /> should not result in a panic from the kernel driver.<br /> <br /> Fix this by setting dwc-&gt;gadget to NULL in the failure path of<br /> dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out<br /> unless the gadget pointer is valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled<br /> <br /> When only PHY1 is used (for example on Odroid-HC4), the regmap init code<br /> uses the usb2 ports when doesn&amp;#39;t initialize the PHY1 regmap entry.<br /> <br /> This fixes:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> ...<br /> pc : regmap_update_bits_base+0x40/0xa0<br /> lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8<br /> ...<br /> Call trace:<br /> regmap_update_bits_base+0x40/0xa0<br /> dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8<br /> dwc3_meson_g12a_usb2_init+0x7c/0xc8<br /> dwc3_meson_g12a_usb_init+0x28/0x48<br /> dwc3_meson_g12a_probe+0x298/0x540<br /> platform_probe+0x70/0xe0<br /> really_probe+0xf0/0x4d8<br /> driver_probe_device+0xfc/0x168<br /> ...