Vulnerabilities

Book Store Management System v1.0 was discovered to contain a cross-site scripting (XSS) vulnerability in /bsms_ci/index.php/category. This vulnerability allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the category parameter.

Book Store Management System v1.0 was discovered to contain a cross-site scripting (XSS) vulnerability in /bsms_ci/index.php/history. This vulnerability allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the history parameter.

Incorrect access control in Book Store Management System v1 allows attackers to access unauthorized pages and execute administrative functions without authenticating.

A local file inclusion (LFI) in Customer Support System v1 allows attackers to include internal PHP files and gain unauthorized acces via manipulation of the page= parameter at /customer_support/index.php.

A directory listing vulnerability in Customer Support System v1 allows attackers to list directories and sensitive files within the application without requiring authorization.

Cross Site Scripting vulnerability in Petrol Pump Mangement Software v.1.0 allows an attacker to execute arbitrary code via a crafted payload to the Address parameter in the add_invoices.php component.

Cross Site Scripting vulnerability in Petrol Pump Mangement Software v.1.0 allows an attacker to execute arbitrary code via a crafted payload to the image parameter in the profile.php component.

SQL Injection vulnerability in Petrol Pump Mangement Software v.1.0 allows an attacker to execute arbitrary code via a crafted payload to the email address parameter in the index.php component.

File Upload vulnerability in Petrol Pump Mangement Software v.1.0 allows an attacker to execute arbitrary code via a crafted payload to the email Image parameter in the profile.php component.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Return CQE error if invalid lkey was supplied<br /> <br /> RXE is missing update of WQE status in LOCAL_WRITE failures. This caused<br /> the following kernel panic if someone sent an atomic operation with an<br /> explicitly wrong lkey.<br /> <br /> [leonro@vm ~]$ mkt test<br /> test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ...<br /> WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe]<br /> Modules linked in: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core<br /> CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe]<br /> Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff<br /> RSP: 0018:ffff8880158af090 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652<br /> RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210<br /> RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b<br /> R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8<br /> R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c<br /> FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> rxe_do_task+0x130/0x230 [rdma_rxe]<br /> rxe_rcv+0xb11/0x1df0 [rdma_rxe]<br /> rxe_loopback+0x157/0x1e0 [rdma_rxe]<br /> rxe_responder+0x5532/0x7620 [rdma_rxe]<br /> rxe_do_task+0x130/0x230 [rdma_rxe]<br /> rxe_rcv+0x9c8/0x1df0 [rdma_rxe]<br /> rxe_loopback+0x157/0x1e0 [rdma_rxe]<br /> rxe_requester+0x1efd/0x58c0 [rdma_rxe]<br /> rxe_do_task+0x130/0x230 [rdma_rxe]<br /> rxe_post_send+0x998/0x1860 [rdma_rxe]<br /> ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs]<br /> ib_uverbs_write+0x847/0xc80 [ib_uverbs]<br /> vfs_write+0x1c5/0x840<br /> ksys_write+0x176/0x1d0<br /> do_syscall_64+0x3f/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

Certain HP DesignJet print products are potentially vulnerable to information disclosure related to accessing memory out-of-bounds when using the general-purpose gateway (GGW) over port 9220.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry<br /> <br /> do_mq_timedreceive calls wq_sleep with a stack local address. The<br /> sender (do_mq_timedsend) uses this address to later call pipelined_send.<br /> <br /> This leads to a very hard to trigger race where a do_mq_timedreceive<br /> call might return and leave do_mq_timedsend to rely on an invalid<br /> address, causing the following crash:<br /> <br /> RIP: 0010:wake_q_add_safe+0x13/0x60<br /> Call Trace:<br /> __x64_sys_mq_timedsend+0x2a9/0x490<br /> do_syscall_64+0x80/0x680<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> RIP: 0033:0x7f5928e40343<br /> <br /> The race occurs as:<br /> <br /> 1. do_mq_timedreceive calls wq_sleep with the address of `struct<br /> ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it<br /> holds a valid `struct ext_wait_queue *` as long as the stack has not<br /> been overwritten.<br /> <br /> 2. `ewq_addr` gets added to info-&gt;e_wait_q[RECV].list in wq_add, and<br /> do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call<br /> __pipelined_op.<br /> <br /> 3. Sender calls __pipelined_op::smp_store_release(&amp;this-&gt;state,<br /> STATE_READY). Here is where the race window begins. (`this` is<br /> `ewq_addr`.)<br /> <br /> 4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it<br /> will see `state == STATE_READY` and break.<br /> <br /> 5. do_mq_timedreceive returns, and `ewq_addr` is no longer guaranteed<br /> to be a `struct ext_wait_queue *` since it was on do_mq_timedreceive&amp;#39;s<br /> stack. (Although the address may not get overwritten until another<br /> function happens to touch it, which means it can persist around for an<br /> indefinite time.)<br /> <br /> 6. do_mq_timedsend::__pipelined_op() still believes `ewq_addr` is a<br /> `struct ext_wait_queue *`, and uses it to find a task_struct to pass to<br /> the wake_q_add_safe call. In the lucky case where nothing has<br /> overwritten `ewq_addr` yet, `ewq_addr-&gt;task` is the right task_struct.<br /> In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a<br /> bogus address as the receiver&amp;#39;s task_struct causing the crash.<br /> <br /> do_mq_timedsend::__pipelined_op() should not dereference `this` after<br /> setting STATE_READY, as the receiver counterpart is now free to return.<br /> Change __pipelined_op to call wake_q_add_safe on the receiver&amp;#39;s<br /> task_struct returned by get_task_struct, instead of dereferencing `this`<br /> which sits on the receiver&amp;#39;s stack.<br /> <br /> As Manfred pointed out, the race potentially also exists in<br /> ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix<br /> those in the same way.