Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ieee802154: ca8210: Stop leaking skb&amp;#39;s<br /> <br /> Upon error the ieee802154_xmit_complete() helper is not called. Only<br /> ieee802154_wake_queue() is called manually. We then leak the skb<br /> structure.<br /> <br /> Free the skb structure upon error before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: uniphier: fix reference count leak in uniphier_spi_probe()<br /> <br /> The issue happens in several error paths in uniphier_spi_probe().<br /> When either dma_get_slave_caps() or devm_spi_register_master() returns<br /> an error code, the function forgets to decrease the refcount of both<br /> `dma_rx` and `dma_tx` objects, which may lead to refcount leaks.<br /> <br /> Fix it by decrementing the reference count of specific objects in<br /> those error paths.

An authenticated user can upload arbitrary files in the upload <br /> function for collection preview images. An attacker may upload an HTML <br /> file that includes malicious JavaScript code which will be executed if a<br /> user visits the direct URL of the collection preview image (Stored <br /> Cross Site Scripting). It is also possible to upload SVG files that <br /> include nested XML entities. Those are parsed when a user visits the <br /> direct URL of the collection preview image, which may be utilized for a <br /> Denial of Service attack.<br /> <br /> This issue affects edu-sharing:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: pciehp: Fix infinite loop in IRQ handler upon power fault<br /> <br /> The Power Fault Detected bit in the Slot Status register differs from<br /> all other hotplug events in that it is sticky: It can only be cleared<br /> after turning off slot power. Per PCIe r5.0, sec. 6.7.1.8:<br /> <br /> If a power controller detects a main power fault on the hot-plug slot,<br /> it must automatically set its internal main power fault latch [...].<br /> The main power fault latch is cleared when software turns off power to<br /> the hot-plug slot.<br /> <br /> The stickiness used to cause interrupt storms and infinite loops which<br /> were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault<br /> interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable<br /> software notification on empty slots").<br /> <br /> Unfortunately in 2020 the infinite loop issue was inadvertently<br /> reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt<br /> race"): The hardirq handler pciehp_isr() clears the PFD bit until<br /> pciehp&amp;#39;s power_fault_detected flag is set. That happens in the IRQ<br /> thread pciehp_ist(), which never learns of the event because the hardirq<br /> handler is stuck in an infinite loop. Fix by setting the<br /> power_fault_detected flag already in the hardirq handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9170/1: fix panic when kasan and kprobe are enabled<br /> <br /> arm32 uses software to simulate the instruction replaced<br /> by kprobe. some instructions may be simulated by constructing<br /> assembly functions. therefore, before executing instruction<br /> simulation, it is necessary to construct assembly function<br /> execution environment in C language through binding registers.<br /> after kasan is enabled, the register binding relationship will<br /> be destroyed, resulting in instruction simulation errors and<br /> causing kernel panic.<br /> <br /> the kprobe emulate instruction function is distributed in three<br /> files: actions-common.c actions-arm.c actions-thumb.c, so disable<br /> KASAN when compiling these files.<br /> <br /> for example, use kprobe insert on cap_capable+20 after kasan<br /> enabled, the cap_capable assembly code is as follows:<br /> :<br /> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}<br /> e1a05000 mov r5, r0<br /> e280006c add r0, r0, #108 ; 0x6c<br /> e1a04001 mov r4, r1<br /> e1a06002 mov r6, r2<br /> e59fa090 ldr sl, [pc, #144] ;<br /> ebfc7bf8 bl c03aa4b4 <br /> e595706c ldr r7, [r5, #108] ; 0x6c<br /> e2859014 add r9, r5, #20<br /> ......<br /> The emulate_ldr assembly code after enabling kasan is as follows:<br /> c06f1384 :<br /> e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}<br /> e282803c add r8, r2, #60 ; 0x3c<br /> e1a05000 mov r5, r0<br /> e7e37855 ubfx r7, r5, #16, #4<br /> e1a00008 mov r0, r8<br /> e1a09001 mov r9, r1<br /> e1a04002 mov r4, r2<br /> ebf35462 bl c03c6530 <br /> e357000f cmp r7, #15<br /> e7e36655 ubfx r6, r5, #12, #4<br /> e205a00f and sl, r5, #15<br /> 0a000001 beq c06f13bc <br /> e0840107 add r0, r4, r7, lsl #2<br /> ebf3545c bl c03c6530 <br /> e084010a add r0, r4, sl, lsl #2<br /> ebf3545a bl c03c6530 <br /> e2890010 add r0, r9, #16<br /> ebf35458 bl c03c6530 <br /> e5990010 ldr r0, [r9, #16]<br /> e12fff30 blx r0<br /> e356000f cm r6, #15<br /> 1a000014 bne c06f1430 <br /> e1a06000 mov r6, r0<br /> e2840040 add r0, r4, #64 ; 0x40<br /> ......<br /> <br /> when running in emulate_ldr to simulate the ldr instruction, panic<br /> occurred, and the log is as follows:<br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 00000090<br /> pgd = ecb46400<br /> [00000090] *pgd=2e0fa003, *pmd=00000000<br /> Internal error: Oops: 206 [#1] SMP ARM<br /> PC is at cap_capable+0x14/0xb0<br /> LR is at emulate_ldr+0x50/0xc0<br /> psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c<br /> r10: 00000000 r9 : c30897f4 r8 : ecd63cd4<br /> r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98<br /> r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008<br /> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user<br /> Control: 32c5387d Table: 2d546400 DAC: 55555555<br /> Process bash (pid: 1643, stack limit = 0xecd60190)<br /> (cap_capable) from (kprobe_handler+0x218/0x340)<br /> (kprobe_handler) from (kprobe_trap_handler+0x24/0x48)<br /> (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)<br /> (do_undefinstr) from (__und_svc_finish+0x0/0x30)<br /> (__und_svc_finish) from (cap_capable+0x18/0xb0)<br /> (cap_capable) from (cap_vm_enough_memory+0x38/0x48)<br /> (cap_vm_enough_memory) from<br /> (security_vm_enough_memory_mm+0x48/0x6c)<br /> (security_vm_enough_memory_mm) from<br /> (copy_process.constprop.5+0x16b4/0x25c8)<br /> (copy_process.constprop.5) from (_do_fork+0xe8/0x55c)<br /> (_do_fork) from (SyS_clone+0x1c/0x24)<br /> (SyS_clone) from (__sys_trace_return+0x0/0x10)<br /> Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix queues reservation for XDP<br /> <br /> When XDP was configured on a system with large number of CPUs<br /> and X722 NIC there was a call trace with NULL pointer dereference.<br /> <br /> i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12<br /> i40e 0000:87:00.0: setup of MAIN VSI failed<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]<br /> Call Trace:<br /> ? i40e_reconfig_rss_queues+0x130/0x130 [i40e]<br /> dev_xdp_install+0x61/0xe0<br /> dev_xdp_attach+0x18a/0x4c0<br /> dev_change_xdp_fd+0x1e6/0x220<br /> do_setlink+0x616/0x1030<br /> ? ahci_port_stop+0x80/0x80<br /> ? ata_qc_issue+0x107/0x1e0<br /> ? lock_timer_base+0x61/0x80<br /> ? __mod_timer+0x202/0x380<br /> rtnl_setlink+0xe5/0x170<br /> ? bpf_lsm_binder_transaction+0x10/0x10<br /> ? security_capable+0x36/0x50<br /> rtnetlink_rcv_msg+0x121/0x350<br /> ? rtnl_calcit.isra.0+0x100/0x100<br /> netlink_rcv_skb+0x50/0xf0<br /> netlink_unicast+0x1d3/0x2a0<br /> netlink_sendmsg+0x22a/0x440<br /> sock_sendmsg+0x5e/0x60<br /> __sys_sendto+0xf0/0x160<br /> ? __sys_getsockname+0x7e/0xc0<br /> ? _copy_from_user+0x3c/0x80<br /> ? __sys_setsockopt+0xc8/0x1a0<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f83fa7a39e0<br /> <br /> This was caused by PF queue pile fragmentation due to<br /> flow director VSI queue being placed right after main VSI.<br /> Because of this main VSI was not able to resize its<br /> queue allocation for XDP resulting in no queues allocated<br /> for main VSI when XDP was turned on.<br /> <br /> Fix this by always allocating last queue in PF queue pile<br /> for a flow director VSI.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: refactor malicious adv data check<br /> <br /> Check for out-of-bound read was being performed at the end of while<br /> num_reports loop, and would fill journal with false positives. Added<br /> check to beginning of loop processing so that it doesn&amp;#39;t get checked<br /> after ptr has been advanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: improve size validations for received domain records<br /> <br /> The function tipc_mon_rcv() allows a node to receive and process<br /> domain_record structs from peer nodes to track their views of the<br /> network topology.<br /> <br /> This patch verifies that the number of members in a received domain<br /> record does not exceed the limit defined by MAX_MON_DOMAIN, something<br /> that may otherwise lead to a stack overflow.<br /> <br /> tipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where<br /> we are reading a 32 bit message data length field into a uint16. To<br /> avert any risk of bit overflow, we add an extra sanity check for this in<br /> that function. We cannot see that happen with the current code, but<br /> future designers being unaware of this risk, may introduce it by<br /> allowing delivery of very large (&gt; 64k) sk buffers from the bearer<br /> layer. This potential problem was identified by Eric Dumazet.<br /> <br /> This fixes CVE-2022-0435

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix error handling in ext4_fc_record_modified_inode()<br /> <br /> Current code does not fully takes care of krealloc() error case, which<br /> could lead to silent memory corruption or a kernel bug. This patch<br /> fixes that.<br /> <br /> Also it cleans up some duplicated error handling logic from various<br /> functions in fast_commit.c file.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel/pt: Fix crash with stop filters in single-range mode<br /> <br /> Add a check for !buf-&gt;single before calling pt_buffer_region_size in a<br /> place where a missing check can cause a kernel crash.<br /> <br /> Fixes a bug introduced by commit 670638477aed ("perf/x86/intel/pt:<br /> Opportunistically use single range output mode"), which added a<br /> support for PT single-range output mode. Since that commit if a PT<br /> stop filter range is hit while tracing, the kernel will crash because<br /> of a null pointer dereference in pt_handle_status due to calling<br /> pt_buffer_region_size without a ToPA configured.<br /> <br /> The commit which introduced single-range mode guarded almost all uses of<br /> the ToPA buffer variables with checks of the buf-&gt;single variable, but<br /> missed the case where tracing was stopped by the PT hardware, which<br /> happens when execution hits a configured stop filter.<br /> <br /> Tested that hitting a stop filter while PT recording successfully<br /> records a trace with this patch but crashes without this patch.

Stack-based buffer overflow vulnerability in the SonicOS HTTP server allows an authenticated remote attacker to cause Denial of Service (DoS) via sscanf function.

Heap-based buffer overflow vulnerability in the SonicOS SSL-VPN allows an authenticated remote attacker to cause Denial of Service (DoS) via memcpy function.