Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net:sfc: fix non-freed irq in legacy irq mode<br /> <br /> SFC driver can be configured via modparam to work using MSI-X, MSI or<br /> legacy IRQ interrupts. In the last one, the interrupt was not properly<br /> released on module remove.<br /> <br /> It was not freed because the flag irqs_hooked was not set during<br /> initialization in the case of using legacy IRQ.<br /> <br /> Example of (trimmed) trace during module remove without this fix:<br /> <br /> remove_proc_entry: removing non-empty directory &amp;#39;irq/125&amp;#39;, leaking at least &amp;#39;0000:3b:00.1&amp;#39;<br /> WARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170<br /> ...trimmed...<br /> Call Trace:<br /> unregister_irq_proc+0xe3/0x100<br /> free_desc+0x29/0x70<br /> irq_free_descs+0x47/0x70<br /> mp_unmap_irq+0x58/0x60<br /> acpi_unregister_gsi_ioapic+0x2a/0x40<br /> acpi_pci_irq_disable+0x78/0xb0<br /> pci_disable_device+0xd1/0x100<br /> efx_pci_remove+0xa1/0x1e0 [sfc]<br /> pci_device_remove+0x38/0xa0<br /> __device_release_driver+0x177/0x230<br /> driver_detach+0xcb/0x110<br /> bus_remove_driver+0x58/0xd0<br /> pci_unregister_driver+0x2a/0xb0<br /> efx_exit_module+0x24/0xf40 [sfc]<br /> __do_sys_delete_module.constprop.0+0x171/0x280<br /> ? exit_to_user_mode_prepare+0x83/0x1d0<br /> do_syscall_64+0x3d/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f9f9385800b<br /> ...trimmed...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isdn: mISDN: netjet: Fix crash in nj_probe:<br /> <br /> &amp;#39;nj_setup&amp;#39; in netjet.c might fail with -EIO and in this case<br /> &amp;#39;card-&gt;irq&amp;#39; is initialized and is bigger than zero. A subsequent call to<br /> &amp;#39;nj_release&amp;#39; will free the irq that has not been requested.<br /> <br /> Fix this bug by deleting the previous assignment to &amp;#39;card-&gt;irq&amp;#39; and just<br /> keep the assignment before &amp;#39;request_irq&amp;#39;.<br /> <br /> The KASAN&amp;#39;s log reveals it:<br /> <br /> [ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826<br /> free_irq+0x100/0x480<br /> [ 3.355112 ] Modules linked in:<br /> [ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted<br /> 5.13.0-rc1-00144-g25a1298726e #13<br /> [ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> [ 3.356552 ] RIP: 0010:free_irq+0x100/0x480<br /> [ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18<br /> 4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5<br /> ff 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80<br /> [ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082<br /> [ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:<br /> 0000000000000000<br /> [ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:<br /> 00000000ffffffff<br /> [ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:<br /> 0000000000000000<br /> [ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:<br /> 0000000000000000<br /> [ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:<br /> ffff888104dc80a8<br /> [ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)<br /> knlGS:0000000000000000<br /> [ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:<br /> 00000000000006f0<br /> [ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [ 3.362175 ] Call Trace:<br /> [ 3.362175 ] nj_release+0x51/0x1e0<br /> [ 3.362175 ] nj_probe+0x450/0x950<br /> [ 3.362175 ] ? pci_device_remove+0x110/0x110<br /> [ 3.362175 ] local_pci_probe+0x45/0xa0<br /> [ 3.362175 ] pci_device_probe+0x12b/0x1d0<br /> [ 3.362175 ] really_probe+0x2a9/0x610<br /> [ 3.362175 ] driver_probe_device+0x90/0x1d0<br /> [ 3.362175 ] ? mutex_lock_nested+0x1b/0x20<br /> [ 3.362175 ] device_driver_attach+0x68/0x70<br /> [ 3.362175 ] __driver_attach+0x124/0x1b0<br /> [ 3.362175 ] ? device_driver_attach+0x70/0x70<br /> [ 3.362175 ] bus_for_each_dev+0xbb/0x110<br /> [ 3.362175 ] ? rdinit_setup+0x45/0x45<br /> [ 3.362175 ] driver_attach+0x27/0x30<br /> [ 3.362175 ] bus_add_driver+0x1eb/0x2a0<br /> [ 3.362175 ] driver_register+0xa9/0x180<br /> [ 3.362175 ] __pci_register_driver+0x82/0x90<br /> [ 3.362175 ] ? w6692_init+0x38/0x38<br /> [ 3.362175 ] nj_init+0x36/0x38<br /> [ 3.362175 ] do_one_initcall+0x7f/0x3d0<br /> [ 3.362175 ] ? rdinit_setup+0x45/0x45<br /> [ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80<br /> [ 3.362175 ] kernel_init_freeable+0x2aa/0x301<br /> [ 3.362175 ] ? rest_init+0x2c0/0x2c0<br /> [ 3.362175 ] kernel_init+0x18/0x190<br /> [ 3.362175 ] ? rest_init+0x2c0/0x2c0<br /> [ 3.362175 ] ? rest_init+0x2c0/0x2c0<br /> [ 3.362175 ] ret_from_fork+0x1f/0x30<br /> [ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...<br /> [ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted<br /> 5.13.0-rc1-00144-g25a1298726e #13<br /> [ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> [ 3.362175 ] Call Trace:<br /> [ 3.362175 ] dump_stack+0xba/0xf5<br /> [ 3.362175 ] ? free_irq+0x100/0x480<br /> [ 3.362175 ] panic+0x15a/0x3f2<br /> [ 3.362175 ] ? __warn+0xf2/0x150<br /> [ 3.362175 ] ? free_irq+0x100/0x480<br /> [ 3.362175 ] __warn+0x108/0x150<br /> [ 3.362175 ] ? free_irq+0x100/0x480<br /> [ 3.362175 ] report_bug+0x119/0x1c0<br /> [ 3.362175 ] handle_bug+0x3b/0x80<br /> [ 3.362175 ] exc_invalid_op+0x18/0x70<br /> [ 3.362175 ] asm_exc_invalid_op+0x12/0x20<br /> [ 3.362175 ] RIP: 0010:free_irq+0x100<br /> ---truncated---

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).