Vulnerabilities

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 /> bus: mhi: core: Validate channel ID when processing command completions<br /> <br /> MHI reads the channel ID from the event ring element sent by the<br /> device which can be any value between 0 and 255. In order to<br /> prevent any out of bound accesses, add a check against the maximum<br /> number of channels supported by the controller and those channels<br /> not configured yet so as to skip processing of that event ring<br /> element.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: auxiliary bus: Fix memory leak when driver_register() fail<br /> <br /> If driver_register() returns with error we need to free the memory<br /> allocated for auxdrv-&gt;driver.name before returning from<br /> __auxiliary_driver_register()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()<br /> <br /> Fix an 11-year old bug in ngene_command_config_free_buf() while<br /> addressing the following warnings caught with -Warray-bounds:<br /> <br /> arch/alpha/include/asm/string.h:22:16: warning: &amp;#39;__builtin_memcpy&amp;#39; offset [12, 16] from the object at &amp;#39;com&amp;#39; is out of the bounds of referenced subobject &amp;#39;config&amp;#39; with type &amp;#39;unsigned char&amp;#39; at offset 10 [-Warray-bounds]<br /> arch/x86/include/asm/string_32.h:182:25: warning: &amp;#39;__builtin_memcpy&amp;#39; offset [12, 16] from the object at &amp;#39;com&amp;#39; is out of the bounds of referenced subobject &amp;#39;config&amp;#39; with type &amp;#39;unsigned char&amp;#39; at offset 10 [-Warray-bounds]<br /> <br /> The problem is that the original code is trying to copy 6 bytes of<br /> data into a one-byte size member _config_ of the wrong structue<br /> FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a<br /> legitimate compiler warning because memcpy() overruns the length<br /> of &amp;com.cmd.ConfigureBuffers.config. It seems that the right<br /> structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains<br /> 6 more members apart from the header _hdr_. Also, the name of<br /> the function ngene_command_config_free_buf() suggests that the actual<br /> intention is to ConfigureFreeBuffers, instead of ConfigureBuffers<br /> (which takes place in the function ngene_command_config_buf(), above).<br /> <br /> Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS<br /> into new struct config, and use &amp;com.cmd.ConfigureFreeBuffers.config as<br /> the destination address, instead of &amp;com.cmd.ConfigureBuffers.config,<br /> when calling memcpy().<br /> <br /> This also helps with the ongoing efforts to globally enable<br /> -Warray-bounds and get us closer to being able to tighten the<br /> FORTIFY_SOURCE routines on memcpy().

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 ]---