Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel: himax-hx83102: Add a check to prevent NULL pointer dereference<br /> <br /> drm_mode_duplicate() could return NULL due to lack of memory,<br /> which will then call NULL pointer dereference. Add a check to<br /> prevent it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udmabuf: fix memory leak on last export_udmabuf() error path<br /> <br /> In export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a<br /> dma_buf owning the udmabuf has already been created; but the error handling<br /> in udmabuf_create() will tear down the udmabuf without doing anything about<br /> the containing dma_buf.<br /> <br /> This leaves a dma_buf in memory that contains a dangling pointer; though<br /> that doesn&amp;#39;t seem to lead to anything bad except a memory leak.<br /> <br /> Fix it by moving the dma_buf_fd() call out of export_udmabuf() so that we<br /> can give it different error handling.<br /> <br /> Note that the shape of this code changed a lot in commit 5e72b2b41a21<br /> ("udmabuf: convert udmabuf driver to use folios"); but the memory leak<br /> seems to have existed since the introduction of udmabuf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: netdevsim: fix nsim_pp_hold_write()<br /> <br /> nsim_pp_hold_write() has two problems:<br /> <br /> 1) It may return with rtnl held, as found by syzbot.<br /> <br /> 2) Its return value does not propagate an error if any.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: no double destroy workqueue<br /> <br /> There are some FW error handling paths that can cause us to<br /> try to destroy the workqueue more than once, so let&amp;#39;s be sure<br /> we&amp;#39;re checking for that.<br /> <br /> The case where this popped up was in an AER event where the<br /> handlers got called in such a way that ionic_reset_prepare()<br /> and thus ionic_dev_teardown() got called twice in a row.<br /> The second time through the workqueue was already destroyed,<br /> and destroy_workqueue() choked on the bad wq pointer.<br /> <br /> We didn&amp;#39;t hit this in AER handler testing before because at<br /> that time we weren&amp;#39;t using a private workqueue. Later we<br /> replaced the use of the system workqueue with our own private<br /> workqueue but hadn&amp;#39;t rerun the AER handler testing since then.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: Fix netdev notifier unregister on failure<br /> <br /> If register_netdev() fails, then the driver leaks the netdev notifier.<br /> Fix this by calling ionic_lif_unregister() on register_netdev()<br /> failure. This will also call ionic_lif_unregister_phc() if it has<br /> already been registered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: prevent bad user input in nsim_dev_health_break_write()<br /> <br /> If either a zero count or a large one is provided, kernel can crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic()<br /> <br /> Packets injected by the CPU should have a SRC_PORT field equal to the<br /> CPU port module index in the Analyzer block (ocelot-&gt;num_phys_ports).<br /> <br /> The blamed commit copied the ocelot_ifh_set_basic() call incorrectly<br /> from ocelot_xmit_common() in net/dsa/tag_ocelot.c. Instead of calling<br /> with "x", it calls with BIT_ULL(x), but the field is not a port mask,<br /> but rather a single port index.<br /> <br /> [ side note: this is the technical debt of code duplication :( ]<br /> <br /> The error used to be silent and doesn&amp;#39;t appear to have other<br /> user-visible manifestations, but with new changes in the packing<br /> library, it now fails loudly as follows:<br /> <br /> ------------[ cut here ]------------<br /> Cannot store 0x40 inside bits 46-43 - will truncate<br /> sja1105 spi2.0: xmit timed out<br /> WARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198<br /> sja1105 spi2.0: timed out polling for tstamp<br /> CPU: 1 UID: 0 PID: 102 Comm: felix_xmit<br /> Tainted: G W N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605<br /> Call trace:<br /> __pack+0x90/0x198 (P)<br /> __pack+0x90/0x198 (L)<br /> packing+0x78/0x98<br /> ocelot_ifh_set_basic+0x260/0x368<br /> ocelot_port_inject_frame+0xa8/0x250<br /> felix_port_deferred_xmit+0x14c/0x258<br /> kthread_worker_fn+0x134/0x350<br /> kthread+0x114/0x138<br /> <br /> The code path pertains to the ocelot switchdev driver and to the felix<br /> secondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q.<br /> <br /> The messenger (packing) is not really to blame, so fix the original<br /> commit instead.

A vulnerability, which was classified as critical, was found in Codezips Event Management System 1.0. Affected is an unknown function of the file /contact.php. The manipulation of the argument title leads to sql injection. It is possible to launch the attack 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 /> ceph: fix memory leak in ceph_direct_read_write()<br /> <br /> The bvecs array which is allocated in iter_get_bvecs_alloc() is leaked<br /> and pages remain pinned if ceph_alloc_sparse_ext_map() fails.<br /> <br /> There is no need to delay the allocation of sparse_ext map until after<br /> the bvecs array is set up, so fix this by moving sparse_ext allocation<br /> a bit earlier. Also, make a similar adjustment in __ceph_sync_read()<br /> for consistency (a leak of the same kind in __ceph_sync_read() has been<br /> addressed differently).