Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: check if iowq is killed before queuing<br /> <br /> task work can be executed after the task has gone through io_uring<br /> termination, whether it&amp;#39;s the final task_work run or the fallback path.<br /> In this case, task work will find -&gt;io_wq being already killed and<br /> null&amp;#39;ed, which is a problem if it then tries to forward the request to<br /> io_queue_iowq(). Make io_queue_iowq() fail requests in this case.<br /> <br /> Note that it also checks PF_KTHREAD, because the user can first close<br /> a DEFER_TASKRUN ring and shortly after kill the task, in which case<br /> -&gt;iowq check would race.

A vulnerability, which was classified as critical, has been found in 1000 Projects Human Resource Management System 1.0. This issue affects some unknown processing of the file /employeeview.php. The manipulation of the argument search leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

A vulnerability classified as critical was found in 1000 Projects Attendance Tracking Management System 1.0. This vulnerability affects unknown code of the file /admin/attendance_action.php. The manipulation of the argument attendance_id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.