Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Grokability Snipe-IT before 8.1.0 has incorrect authorization for accessing asset information.

A vulnerability was found in gorhill uBlock Origin up to 1.63.3b16. It has been classified as problematic. Affected is the function currentStateChanged of the file src/js/1p-filters.js of the component UI. The manipulation leads to inefficient regular expression complexity. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.63.3b17 is able to address this issue. The patch is identified as eaedaf5b10d2f7857c6b77fbf7d4a80681d4d46c. It is recommended to upgrade the affected component.

A vulnerability was found in PHPGuruku Online DJ Booking Management System 1.0 and classified as critical. This issue affects some unknown processing of the file /admin/booking-bwdates-reports-details.php. The manipulation of the argument fromdate leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Other parameters might be affected as well.

In the obfstr crate before 0.4.4 for Rust, the obfstr! argument type is not restricted to string slices, leading to invalid UTF-8 conversion that produces an invalid value.

A vulnerability has been found in PHPGurukul Online Birth Certificate System 1.0 and classified as critical. This vulnerability affects unknown code of the file /admin/search.php. The manipulation of the argument searchdata leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

TOTOLINK A950RG V4.1.2cu.5204_B20210112 contains a command execution vulnerability in the setDeviceName interface of the /lib/cste_modules/global.so library, specifically in the processing of the deviceMac parameter.

Flags SDK is an open-source feature flags toolkit for Next.js and SvelteKit. Impacted versions include flags from 3.2.0 and prior and @vercel/flags from 3.1.1 and prior as certain circumstances allows a bad actor with detailed knowledge of the vulnerability to list all flags returned by the flags discovery endpoint (.well-known/vercel/flags). This vulnerability allows for information disclosure, where a bad actor could gain access to a list of all feature flags exposed through the flags discovery endpoint, including the flag names, flag descriptions, available options and their labels (e.g. true, false), and default flag values. This issue has been patched in flags@4.0.0, users of flags and @vercel/flags should also migrate to flags@4.0.0.

Vault Community, Vault Enterprise (“Vault”) Azure Auth method did not correctly validate the claims in the Azure-issued token, resulting in the potential bypass of the bound_locations parameter on login. Fixed in Vault Community Edition 1.19.1 and Vault Enterprise 1.19.1, 1.18.7, 1.17.14, 1.16.18.

A vulnerability classified as critical was found in Casdoor up to 1.811.0. This vulnerability affects the function HandleScim of the file controllers/scim.go of the component SCIM User Creation Endpoint. The manipulation leads to authorization bypass. The attack can be initiated remotely. Upgrading to version 1.812.0 is able to address this issue. The name of the patch is 3d12ac8dc2282369296c3386815c00a06c6a92fe. It is recommended to upgrade the affected component.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix wrong kunmap when using LZMA on HIGHMEM platforms<br /> <br /> As the call trace shown, the root cause is kunmap incorrect pages:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000<br /> CPU: 1 PID: 40 Comm: kworker/u5:0 Not tainted 6.2.0-rc5 #4<br /> Workqueue: erofs_worker z_erofs_decompressqueue_work<br /> EIP: z_erofs_lzma_decompress+0x34b/0x8ac<br /> z_erofs_decompress+0x12/0x14<br /> z_erofs_decompress_queue+0x7e7/0xb1c<br /> z_erofs_decompressqueue_work+0x32/0x60<br /> process_one_work+0x24b/0x4d8<br /> ? process_one_work+0x1a4/0x4d8<br /> worker_thread+0x14c/0x3fc<br /> kthread+0xe6/0x10c<br /> ? rescuer_thread+0x358/0x358<br /> ? kthread_complete_and_exit+0x18/0x18<br /> ret_from_fork+0x1c/0x28<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The bug is trivial and should be fixed now. It has no impact on<br /> !HIGHMEM platforms.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix another off-by-one fsmap error on 1k block filesystems<br /> <br /> Apparently syzbot figured out that issuing this FSMAP call:<br /> <br /> struct fsmap_head cmd = {<br /> .fmh_count = ...;<br /> .fmh_keys = {<br /> { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },<br /> { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },<br /> },<br /> ...<br /> };<br /> ret = ioctl(fd, FS_IOC_GETFSMAP, &amp;cmd);<br /> <br /> Produces this crash if the underlying filesystem is a 1k-block ext4<br /> filesystem:<br /> <br /> kernel BUG at fs/ext4/ext4.h:3331!<br /> invalid opcode: 0000 [#1] PREEMPT SMP<br /> CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]<br /> RSP: 0018:ffffc90007c03998 EFLAGS: 00010246<br /> RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000<br /> RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11<br /> RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400<br /> R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001<br /> R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398<br /> FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]<br /> __x64_sys_ioctl+0x82/0xa0<br /> do_syscall_64+0x2b/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7fdf20558aff<br /> RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff<br /> RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003<br /> RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010<br /> R13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000<br /> <br /> For GETFSMAP calls, the caller selects a physical block device by<br /> writing its block number into fsmap_head.fmh_keys[01].fmr_device.<br /> To query mappings for a subrange of the device, the starting byte of the<br /> range is written to fsmap_head.fmh_keys[0].fmr_physical and the last<br /> byte of the range goes in fsmap_head.fmh_keys[1].fmr_physical.<br /> <br /> IOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you&amp;#39;d<br /> set the inputs as follows:<br /> <br /> fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3},<br /> fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14},<br /> <br /> Which would return you whatever is mapped in the 12 bytes starting at<br /> physical offset 3.<br /> <br /> The crash is due to insufficient range validation of keys[1] in<br /> ext4_getfsmap_datadev. On 1k-block filesystems, block 0 is not part of<br /> the filesystem, which means that s_first_data_block is nonzero.<br /> ext4_get_group_no_and_offset subtracts this quantity from the blocknr<br /> argument before cracking it into a group number and a block number<br /> within a group. IOWs, block group 0 spans blocks 1-8192 (1-based)<br /> instead of 0-8191 (0-based) like what happens with larger blocksizes.<br /> <br /> The net result of this encoding is that blocknr s_first_data_block);<br /> <br /> The division then operates on -1:<br /> <br /> offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) &gt;&gt;<br /> EXT4_SB(sb)-&gt;s_cluster_bits;<br /> <br /> Leaving an impossibly large group number (2^32-1) in blocknr.<br /> ext4_getfsmap_check_keys checked that keys[0<br /> ---truncated---