Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Several fixes to bpf_msg_pop_data<br /> <br /> Several fixes to bpf_msg_pop_data,<br /> 1. In sk_msg_shift_left, we should put_page<br /> 2. if (len == 0), return early is better<br /> 3. pop the entire sk_msg (last == msg-&gt;sg.size) should be supported<br /> 4. Fix for the value of variable "a"<br /> 5. In sk_msg_shift_left, after shifting, i has already pointed to the next<br /> element. Addtional sk_msg_iter_var_next may result in BUG.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c<br /> <br /> Add error pointer check after calling otx2_mbox_get_rsp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device<br /> <br /> While design wise the idea of converting the driver to use<br /> the hierarchy of the IRQ chips is correct, the implementation<br /> has (inherited) flaws. This was unveiled when platform_get_irq()<br /> had started WARN() on IRQ 0 that is supposed to be a Linux<br /> IRQ number (also known as vIRQ).<br /> <br /> Rework the driver to respect IRQ domain when creating each MFD<br /> device separately, as the domain is not the same for all of them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices<br /> <br /> While design wise the idea of converting the driver to use<br /> the hierarchy of the IRQ chips is correct, the implementation<br /> has (inherited) flaws. This was unveiled when platform_get_irq()<br /> had started WARN() on IRQ 0 that is supposed to be a Linux<br /> IRQ number (also known as vIRQ).<br /> <br /> Rework the driver to respect IRQ domain when creating each MFD<br /> device separately, as the domain is not the same for all of them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix cpu stuck caused by printings during reset<br /> <br /> During reset, cmd to destroy resources such as qp, cq, and mr may fail,<br /> and error logs will be printed. When a large number of resources are<br /> destroyed, there will be lots of printings, and it may lead to a cpu<br /> stuck.<br /> <br /> Delete some unnecessary printings and replace other printing functions<br /> in these paths with the ratelimited version.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/CPU/AMD: Terminate the erratum_1386_microcode array<br /> <br /> The erratum_1386_microcode array requires an empty entry at the end.<br /> Otherwise x86_match_cpu_with_stepping() will continue iterate the array after<br /> it ended.<br /> <br /> Add an empty entry to erratum_1386_microcode to its end.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c<br /> <br /> Adding error pointer check after calling otx2_mbox_get_rsp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c<br /> <br /> Add error pointer check after calling otx2_mbox_get_rsp().

A vulnerability, which was classified as problematic, has been found in code-projects Hostel Management System 1.0. This issue affects some unknown processing of the file /admin/registration.php. The manipulation of the argument fname/mname/lname leads to cross site scripting. The attack may be initiated remotely.

A vulnerability has been found in code-projects Responsive Hotel Site 1.0 and classified as critical. Affected by this vulnerability is an unknown functionality of the file /admin/newsletter.php. The manipulation of the argument eid leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: fix TSO DMA API usage causing oops<br /> <br /> Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap<br /> for non-paged SKB data") moved the assignment of tx_skbuff_dma[]&amp;#39;s<br /> members to be later in stmmac_tso_xmit().<br /> <br /> The buf (dma cookie) and len stored in this structure are passed to<br /> dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that<br /> the dma cookie passed to dma_unmap_single() is the same as the value<br /> returned from dma_map_single(). However, by moving the assignment<br /> later, this is not the case when priv-&gt;dma_cap.addr64 &gt; 32 as "des"<br /> is offset by proto_hdr_len.<br /> <br /> This causes problems such as:<br /> <br /> dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed<br /> <br /> and with DMA_API_DEBUG enabled:<br /> <br /> DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]<br /> <br /> Fix this by maintaining "des" as the original DMA cookie, and use<br /> tso_des to pass the offset DMA cookie to stmmac_tso_allocator().<br /> <br /> Full details of the crashes can be found at:<br /> https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/<br /> https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: protect link down work from execute after lgr freed<br /> <br /> link down work may be scheduled before lgr freed but execute<br /> after lgr freed, which may result in crash. So it is need to<br /> hold a reference before shedule link down work, and put the<br /> reference after work executed or canceled.<br /> <br /> The relevant crash call stack as follows:<br /> list_del corruption. prev-&gt;next should be ffffb638c9c0fe20,<br /> but was 0000000000000000<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:51!<br /> invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1<br /> Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014<br /> Workqueue: events smc_link_down_work [smc]<br /> RIP: 0010:__list_del_entry_valid.cold+0x31/0x47<br /> RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086<br /> RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000<br /> RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38<br /> R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002<br /> R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0<br /> FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> rwsem_down_write_slowpath+0x17e/0x470<br /> smc_link_down_work+0x3c/0x60 [smc]<br /> process_one_work+0x1ac/0x350<br /> worker_thread+0x49/0x2f0<br /> ? rescuer_thread+0x360/0x360<br /> kthread+0x118/0x140<br /> ? __kthread_bind_mask+0x60/0x60<br /> ret_from_fork+0x1f/0x30