Open Redirect in GitHub repository mosparo/mosparo prior to 1.0.2.

Expand Up

@@ -394,7 +394,7 @@ public function switch(Request $request, Project $project): Response

  

// Redirect back to the originally requested path

$targetPath = $request\->query\->get('targetPath', false);

if ($targetPath) {

if ($targetPath && $this\->isLocalUrl($request, $targetPath)) {

return $this\->redirect($targetPath);

}

  

Expand All

@@ -411,4 +411,22 @@ protected function setActiveProject(Request $request, Project $project): bool

  

return true;

}

  

protected function isLocalUrl(Request $request, $url): bool

{

// If the first character is a slash, the URL is relative (only the path) and is local

if (str\_starts\_with($url, '/')) {

return true;

}

  

// If the URL is absolute but starts with the host of mosparo, we can redirect it.

// Add the slash to prevent a redirect when a similar top-level domain is used.

// For example, mosparo.com should not allow a redirect to mosparo.com.au

if (str\_starts\_with($url, $request\->getSchemeAndHttpHost() . '/')) {

return true;

}

  

// The URL does not match the two checks because it's an external URL; no redirect in that case.

return false;

}

}

CVE-2023-5375: Fixed an open redirect in the project switch functionality. · mosparo/mosparo@9d5da36

A cross-site scripting vulnerability exists in Citadel versions prior to 994. When a malicious user sends an instant message with some JavaScript code, the script may be executed on the web browser of the victim user.

**Commit f0dac5ff** authored Sep 15, 2023 by  **Art Cancro**

Browse files

**webcit: sanitize instant messages against XSS type stuff**

parent 08ba8022

*   Changes 2

Hide whitespace changes

Inline Side-by-side

Supports Markdown

0% or .

You are about to add **0 people** to the discussion. Proceed with caution.

Finish editing this message first!

Please register or sign in to comment

CVE-2023-44272: webcit: sanitize instant messages against XSS type stuff (f0dac5ff) · Commits · citadel / Citadel · GitLab

On CPU 0 the check for the SMCCC workaround is called before SMCCC support has been initialized. This resulted in no speculative execution workarounds being installed on CPU 0.

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-23:14.smccc Security Advisory The FreeBSD Project Topic: arm64 boot CPUs may lack speculative execution protections Category: core Module: arm64 Announced: 2023-10-03 Affects: FreeBSD 13.2 Corrected: 2023-09-25 12:13:47 UTC (stable/13, 13.2-STABLE) 2023-10-03 21:29:11 UTC (releng/13.2, 13.2-RELEASE-p4) CVE Name: CVE-2023-5370 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background To mitigate speculative execution side channel attacks on some AArch64 hardware the kernel can call into the boot firmware using the Secure Monitor Call Calling Convention (SMCCC) mechanism. To decide if the kernel needs to use the SMCCC mitigation on a given CPU it can query the firmware if the SMCCC workaround is present. II. Problem Description On CPU 0 the check for the SMCCC workaround is called before SMCCC support has been initialized. III. Impact No speculative execution workarounds are installed on CPU 0. IV. Workaround No workaround is available. Not all AArch64 CPUs are affected. Systems where CPU 0 has the CSV2 and PSTATE.SSBS processor features are unaffected by the speculative execution attacks. The kernel will print the following under CPU 0 on unaffected CPUs: Processor Features 0 = <...CVS2...> Processor Features 1 = <...PSTATE.SSBS...> The Arm Cortex-A35, Cortex-A53, and Cortex-A55 CPUs are unaffected. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date and reboot. Perform one of the following: 1) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the amd64, i386, or (on FreeBSD 13 and later) arm64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-23:14/smccc.patch # fetch https://security.FreeBSD.org/patches/SA-23:14/smccc.patch.asc # gpg --verify smccc.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details This issue is corrected by the corresponding Git commit hash or Subversion revision number in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/13/ 4df1447f2c76 stable/13-n256420 releng/13.2/ 485912e051bb releng/13.2-n254637 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat Or visit the following URL, replacing NNNNNN with the hash: To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmUclU8ACgkQbljekB8A Gu8zqQ//bCjUB/hXZxypEFmnnnyUPr0Y/pzHd1i7EcIFQubd6kosUw4k2VGzwOsi /BwKU4W/MrUyr/wwSkjJ/lmeA+CRX2TAPWPTPC0umnN58fOXRqhKpVAi0yfho+L9 lYUfdLWM0xS4XWsZk7DapjfN8XznLnn6iQrWmFLmZd0ViJFGkGJcxjdWr7aSs7ZX C8v8GoqFx6GUUdOgRERdpZ/2mxi7ibs9LbCt4PUTwKV8clAmq4w4Mv+q4xfZPSnM nXGrTd+t2G5ZrmEZ9Rq32C9JqGaAaQUTp/NsOw8yQq5YVBXanA12VJLx2kdoVKsj 84e3rJz/QTpXTpgiSkVmWdT3ziZW8Zs9aygvUXyzK6C/s2ZiKd8o65dnF3MGCyJs Y7aNgAS51mX/fgPyXwicF/eYA1nm/1AJAK9J/eUBbsi+hu9DW5XjpiLUYAe10KKf 9XsgJ1vTJMKXIv/UAlN0d78SfSfcGyUCbH0qk7zCzw9XfLYj+r9a7de/vnAc0qtm 8Gh0hqbacA6dqtxrNEDC9R1Tp6inf0YYR6gP5HPjjy96FvfZCGmHk5XUmbmk4C4T UylvLXrO4gJiyBXhdZ3P3Mib6HdMWkLMRh095Y2revdAGMv0BrGs3G+eaMVIgNt2 puELCPfLgJF1ljcHV8svdQcuy0Fea2R2R22cqwsT1vPuKqgmP60= =lOTX -----END PGP SIGNATURE-----

CVE-2023-5370

Before correction, the copy_file_range system call checked only for the CAP_READ and CAP_WRITE capabilities on the input and output file descriptors, respectively.  Using an offset is logically equivalent to seeking, and the system call must additionally require the CAP_SEEK capability.

This incorrect privilege check enabled sandboxed processes with only read or write but no seek capability on a file descriptor to read data from or write data to an arbitrary location within the file corresponding to that file descriptor.

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-23:13.capsicum Security Advisory The FreeBSD Project Topic: copy\_file\_range insufficient capability rights check Category: core Module: capsicum Announced: 2023-10-03 Credits: David Chisnall Affects: FreeBSD 13.2 Corrected: 2023-10-02 16:00:27 UTC (stable/13, 13.2-STABLE) 2023-10-03 21:24:41 UTC (releng/13.2, 13.2-RELEASE-p4) CVE Name: CVE-2023-5369 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background Capsicum is a lightweight OS capability and sandbox framework. It provides two kernel primatives, capability mode and capabilities. Capabilities limit operations that can be performed on file descriptors. copy\_file\_range is a system call that performs a kernel copy of a byte range from one file to another or within one file. copy\_file\_range accepts optional pointers to offsets for the input and output file descriptors. II. Problem Description The syscall checked only for the CAP\_READ and CAP\_WRITE capabilities on the input and output file descriptors, respectively. Using an offset is logically equivalent to seeking, and the syscall must additionally require the CAP\_SEEK capability. III. Impact A sandboxed process with only read or write but no seek capability on a file descriptor may be able to read data from or write data to an arbitrary location within the file corresponding to that file descriptor. IV. Workaround No workaround is available. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot. Perform one of the following: 1) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the amd64, i386, or (on FreeBSD 13 and later) arm64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-23:13/capsicum.patch # fetch https://security.FreeBSD.org/patches/SA-23:13/capsicum.patch.asc # gpg --verify capsicum.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details This issue is corrected by the corresponding Git commit hash or Subversion revision number in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/13/ 3f0ce63828dc stable/13-n256458 releng/13.2/ 2d23f6c33431 releng/13.2-n254636 - ------------------------------------------------------------------------- Run the following command to see which files were modified by a particular commit: # git show --stat Or visit the following URL, replacing NNNNNN with the hash: To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmUclU0ACgkQbljekB8A Gu/a3Q//aXO1+HdImFnqAzKEto8E97DEv6vB2HUZAoxrmwSX9VNjkrIo9Z9+LRyL q7WXMcok1OPQCCE3ad+g05eqXwnmJ55CpToP/jEXrOOZRDInK0Z5owZbwVpmyAmW zF/+xoEjcw90H7ReIQQ3+TNGDf025tCoXlTQKdzWtNN6BcY3px4zuDYHPUKgMwSv XJDrjYWBzBede00CnlolwmsBorjvZvRMfllTIpiVTlmtD73s+sRDI7rc768MY0RZ gCplCL9S9EkIGL8XJhDWB2+TsG7nvwrUII5M2u0Db252IK7nmgty4l03PtYotx4p jH/a3oXWKeqExGHJaqNcaUwS6xdu+pvMRuJgY4mH6rd+uvOMbC5jvac3FopSlmXq aVIctA2LCRomyYmVDsWXIGLcBT5cAOhsqkrw+JE0kA/k2Pl6NDNK7HNgo6Fj01TR lVf91A1mTsDJxfymU4SWB/KGgImAnR9e7gHUo4gLZCNyYXvcnFa/ntHoswNZ+12L e/b4+PnHts2X4/+I4K6qdF522yzF/vpyF6UjfwAGtT6qmbmGyW9VbDcn6TIL9I3p IDKJCWeHPBfyspWua2hCUIi3/EwpSFvIECPad3hFT6cej1pZ6hfJt8XT0ma82QGp ocbh3tb3E1phSGvgZitk8J0oyWDehuck3YfZ+6nHMwzPBgmr6Lo= =lS69 -----END PGP SIGNATURE-----

CVE-2023-5369

On an msdosfs filesystem, the 'truncate' or 'ftruncate' system calls under certain circumstances populate the additional space in the file with unallocated data from the underlying disk device, rather than zero bytes.

This may permit a user with write access to files on a msdosfs filesystem to read unintended data (e.g. from a previously deleted file).

\-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-23:12.msdosfs Security Advisory The FreeBSD Project Topic: msdosfs data disclosure Category: core Module: msdosfs (FAT) file system driver Announced: 2023-10-03 Credits: Maxim Suhanov Affects: All supported versions of FreeBSD. Corrected: 2023-07-18 05:46:13 UTC (stable/13, 13.2-STABLE) 2023-10-03 21:23:40 UTC (releng/13.2, 13.2-RELEASE-p4) 2023-09-11 18:51:21 UTC (stable/12, 12.4-STABLE) 2023-10-03 22:15:40 UTC (releng/12.4, 12.4-RELEASE-p6) CVE Name: CVE-2023-5368 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The msdosfs driver provides read and write access to MS-DOS (FAT) file systems. Systems may be configured to allow unprivileged users to have read and write access to mounted msdosfs file systems. II. Problem Description In certain cases using the truncate or ftruncate system call to extend a file size populates the additional space in the file with unallocated data from the underlying disk device, rather than zero bytes. III. Impact A user with write access to files on a msdosfs file system may be able to read unintended data (for example, from a previously deleted file). IV. Workaround No workaround is available. V. Solution Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot. Perform one of the following: 1) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the amd64, i386, or (on FreeBSD 13 and later) arm64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min "Rebooting for a security update" 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. \[FreeBSD 13.2\] # fetch https://security.FreeBSD.org/patches/SA-23:12/msdosfs.13.2.patch # fetch https://security.FreeBSD.org/patches/SA-23:12/msdosfs.13.2.patch.asc # gpg --verify msdosfs.13.2.patch.asc \[FreeBSD 12.4\] # fetch https://security.FreeBSD.org/patches/SA-23:12/msdosfs.12.4.patch # fetch https://security.FreeBSD.org/patches/SA-23:12/msdosfs.12.4.patch.asc # gpg --verify msdosfs.12.4.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details This issue is corrected by the corresponding Git commit hash or Subversion revision number in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/13/ 868f3eadc5e0 stable/13-n255824 releng/13.2/ 7d08a7e6908b releng/13.2-n254635 stable/12/ r373207 releng/12.4/ r373233 - ------------------------------------------------------------------------- For FreeBSD 13 and later: Run the following command to see which files were modified by a particular commit: # git show --stat Or visit the following URL, replacing NNNNNN with the hash: To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD For FreeBSD 12 and earlier: Run the following command to see which files were modified by a particular revision, replacing NNNNNN with the revision number: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmUclUoACgkQbljekB8A Gu9CSw/9G+9cwxNruCQaEOcNGCIUdOe9itmZzVJKVtIIWqXZhq+unXRS0D2YDMdA EKkfGj6GYaPnFlRe7T3cfrqUFhlNMb4Na5SW0wJp8HUqhKzKB4/SNZSs+iXNQE2z WdhYFl582Gg2+vuoije4Z9Idl0WYPqXHXyRC7TCtSwUHDwRsU9jA6g/GNM0X+0dl mOzFxFSSGoORF5aJYtp91KeNwGdNwORc75k6xxMWGGDc0sba9Fbupfrjc/XQ8SaQ tYil3Eomh/cbYOKneppGQo9ohY+PAC1u/2XxRBxXYFCDtNLed4SGEWp4pLKjq2QM X8jkDooTPLwDiVaM6Cps54PmUI3YBrYKSpt3Z1SdTHWyh0hDtpAJb/1f/sPUu90D oWCiFI5p6oZjFNJxskZZ8T6xFgjqiII70ULfHQ3GxGhMZ0Pe5QyzmqIFGvkn0UtX uGechgeL+jwqnyviIFyfVTGORmbcWj60WHajUAVUbb5aF/WV5QS0XDOLhTFkeY/P WQjOBFAH/pf93ahUnA0NuDqAe5yX/3NEXLzMg8bnSBDJRIPRWsPfIE3lqWl0zNmD sdtsugBS74zTM3MUn/Lq5MdtozuvEWK6Hs60i1wuiTMT39X8oE89r5LLVgTyc0Tj 2nML+7TKutMqWgeRvYsXBp6VtEiZd9Qc6nx8FWtSq8UMODa57C8= =T0YO -----END PGP SIGNATURE-----

CVE-2023-5368

An arbitrary file upload vulnerability in the component /admin/plugin.php of Emlog Pro v2.2.0 allows attackers to execute arbitrary code via uploading a crafted PHP file.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2023-44974: emlog/Plugin-getshell.md at main · yangliukk/emlog

Nothings stb 2.28 was discovered to contain a Null Pointer Dereference via the function stbi__convert_format. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted pic file.

**Null Pointer Dereference vulnerability in nothings/stb**

​ Nothings/stb, an image processing library, has a **Null Pointer Dereference** vulnerability in the stbi\_\_convert\_format function, stb\_image.h 2.28(https://github.com/nothings/stb/blob/master/stb\_image.h). This function is called in stbi\_\_pic\_load and is used to parse files in the pic image format. And stbi\_\_pic\_load is called by stbi\_load\_from\_memory.

**Vulnerability causes**

static void \*stbi\_\_pic\_load(stbi\_\_context \*s,int \*px,int \*py,int \*comp,int req\_comp, stbi\_\_result\_info \*ri)
{
   stbi\_uc \*result;
   int i, x,y, internal\_comp;
   STBI\_NOTUSED(ri);

   if (!comp) comp = &internal\_comp;

   for (i=0; i<92; ++i)
      stbi\_\_get8(s);

   x = stbi\_\_get16be(s);
   y = stbi\_\_get16be(s);

   if (y > STBI\_MAX\_DIMENSIONS) return stbi\_\_errpuc("too large","Very large image (corrupt?)");
   if (x > STBI\_MAX\_DIMENSIONS) return stbi\_\_errpuc("too large","Very large image (corrupt?)");

   if (stbi\_\_at\_eof(s))  return stbi\_\_errpuc("bad file","file too short (pic header)");
   if (!stbi\_\_mad3sizes\_valid(x, y, 4, 0)) return stbi\_\_errpuc("too large", "PIC image too large to decode");

   stbi\_\_get32be(s); //skip \`ratio'
   stbi\_\_get16be(s); //skip \`fields'
   stbi\_\_get16be(s); //skip \`pad'

   // intermediate buffer is RGBA
   result = (stbi\_uc \*) stbi\_\_malloc\_mad3(x, y, 4, 0);
   if (!result) return stbi\_\_errpuc("outofmem", "Out of memory");
   memset(result, 0xff, x\*y\*4);

   if (!stbi\_\_pic\_load\_core(s,x,y,comp, result)) {
      STBI\_FREE(result);
      result=0;
   }
   \*px = x;
   \*py = y;
   if (req\_comp == 0) req\_comp = \*comp;
   result=stbi\_\_convert\_format(result,4,req\_comp,x,y);

   return result;
}

​ We can see that the "**result**" variable is assigned NULL after STBI\_FREE and is used again by stbi\_\_convert\_format.

static unsigned char \*stbi\_\_convert\_format(unsigned char \*data, int img\_n, int req\_comp, unsigned int x, unsigned int y)
{
   int i,j;
   unsigned char \*good;

   if (req\_comp == img\_n) return data;
   STBI\_ASSERT(req\_comp >= 1 && req\_comp <= 4);

   good = (unsigned char \*) stbi\_\_malloc\_mad3(req\_comp, x, y, 0);
   if (good == NULL) {
      STBI\_FREE(data);
      return stbi\_\_errpuc("outofmem", "Out of memory");
   }

   for (j=0; j < (int) y; ++j) {
      unsigned char \*src  = data + j \* x \* img\_n   ;
      unsigned char \*dest = good + j \* x \* req\_comp;

      #define STBI\_\_COMBO(a,b)  ((a)\*8+(b))
      #define STBI\_\_CASE(a,b)   case STBI\_\_COMBO(a,b): for(i=x-1; i >= 0; --i, src += a, dest += b)
      // convert source image with img\_n components to one with req\_comp components;
      // avoid switch per pixel, so use switch per scanline and massive macros
      switch (STBI\_\_COMBO(img\_n, req\_comp)) {
         STBI\_\_CASE(1,2) { dest\[0\]=src\[0\]; dest\[1\]=255;                                     } break;
         STBI\_\_CASE(1,3) { dest\[0\]=dest\[1\]=dest\[2\]=src\[0\];                                  } break;
         STBI\_\_CASE(1,4) { dest\[0\]=dest\[1\]=dest\[2\]=src\[0\]; dest\[3\]=255;                     } break;
         STBI\_\_CASE(2,1) { dest\[0\]=src\[0\];                                                  } break;
         STBI\_\_CASE(2,3) { dest\[0\]=dest\[1\]=dest\[2\]=src\[0\];                                  } break;
         STBI\_\_CASE(2,4) { dest\[0\]=dest\[1\]=dest\[2\]=src\[0\]; dest\[3\]=src\[1\];                  } break;
         STBI\_\_CASE(3,4) { dest\[0\]=src\[0\];dest\[1\]=src\[1\];dest\[2\]=src\[2\];dest\[3\]=255;        } break;
         STBI\_\_CASE(3,1) { dest\[0\]=stbi\_\_compute\_y(src\[0\],src\[1\],src\[2\]);                   } break;
         STBI\_\_CASE(3,2) { dest\[0\]=stbi\_\_compute\_y(src\[0\],src\[1\],src\[2\]); dest\[1\] = 255;    } break;
         STBI\_\_CASE(4,1) { dest\[0\]=stbi\_\_compute\_y(src\[0\],src\[1\],src\[2\]);                   } break;
         STBI\_\_CASE(4,2) { dest\[0\]=stbi\_\_compute\_y(src\[0\],src\[1\],src\[2\]); dest\[1\] = src\[3\]; } break;
         STBI\_\_CASE(4,3) { dest\[0\]=src\[0\];dest\[1\]=src\[1\];dest\[2\]=src\[2\];                    } break;
         default: STBI\_ASSERT(0); STBI\_FREE(data); STBI\_FREE(good); return stbi\_\_errpuc("unsupported", "Unsupported format conversion");
      }
      #undef STBI\_\_CASE
   }

   STBI\_FREE(data);
   return good;
}

​ The "**result**" variable will be used again as the "**data**" variable inside stbi\_\_convert\_format, when the "**data**" variable is already a null pointer, and using it again will result in a null pointer dereference.

**Vulnerability reproduce**

​ The environment is shown below.

​ In the "null\_example" folder, use the following command.

​ or

​ We can see the "core dumped".

**Impact**

Denial of service attack

​ Here the "**result**" variable is assigned as a null pointer.

​ Here the null pointer is used as the base address, at which point an error occurs.

CVE-2023-43898: GitHub - peccc/null-stb

An arbitrary file upload vulnerability in the component /content/templates/ of Emlog Pro v2.2.0 allows attackers to execute arbitrary code via uploading a crafted PHP file.

CVE-2023-44973: emlog/Template-getshell.md at main · yangliukk/emlog

An issue was discovered in DTS Monitoring 3.57.0. The parameter common_name within the SSL Certificate check function is vulnerable to OS command injection (blind).

CVE-2023-33271: CVE-Disclosures/CVE-2023-33271.md at main · l4rRyxz/CVE-Disclosures

An issue was discovered in DTS Monitoring 3.57.0. The parameter url within the WGET check function is vulnerable to OS command injection (blind).

Tag

#git