An exploitable information disclosure vulnerability exists in the init_node_manager functionality of F2fs-Tools F2fs.Fsck 1.12 and 1.13. A specially crafted filesystem can be used to disclose information. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

An exploitable information disclosure vulnerability exists in the init_node_manager functionality of F2fs-Tools F2fs.Fsck 1.12 and 1.13. A specially crafted filesystem can be used to disclose information. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

F2fs-Tools F2fs.Fsck 1.12  
F2fs-Tools F2fs.Fsck 1.13

**Product URLs**

https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git

**CVSSv3 Score**

4.4 - CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

**CWE**

CWE-131 - Incorrect Calculation of Buffer Size

**Details**

The f2fs-tools set of utilities is used specifically for creating, checking and fixing f2fs (Flash-Friendly File System) files, a file system that has been replacing ext4 more recently in embedded devices, as it was crafted with eMMC chips and sdcards in mind. Fsck.f2fs more specifically is the file-system checking binary for f2fs partitions, and is where this vulnerability lies.

One of the features of the f2fs filesystem is the NAT section, which is an array of f2fs_nat_entry structs:

    struct f2fs_nat_entry {   
        __u8 version;       /* latest version of cached nat entry */  
        __le32 ino;     /* inode number */   
        __le32 block_addr;  /* block address */  
    } __attribute__((packed));   
    

These f2fs_nat_entry structs allows for extremely quick lookup of block addresses (i.e. physical location on disk), given either a nid (which is the index into the f2fs_nat_entry array), or an inode. One of the steps taken during the f2fs.fsck process is validating this NAT section, including the bitmap that is used for representing the validity of any given nat entry within the nat entry table. This functionality is implemented by the init_node_manager function:

    int init_node_manager(struct f2fs_sb_info *sbi)
    {
        struct f2fs_super_block *sb = F2FS_RAW_SUPER(sbi); // [1]
        struct f2fs_checkpoint *cp = F2FS_CKPT(sbi);       // [2]
        struct f2fs_nm_info *nm_i = NM_I(sbi);             // [3]
        unsigned char *version_bitmap;
        unsigned int nat_segs;
    
        // [...]
        
        nm_i->bitmap_size = __bitmap_size(sbi, NAT_BITMAP); // [4] // le32_to_cpu(ckpt->nat_ver_bitmap_bytesize);
                                
        nm_i->nat_bitmap = malloc(nm_i->bitmap_size);
        if (!nm_i->nat_bitmap)
            return -ENOMkEM;
        version_bitmap = __bitmap_ptr(sbi, NAT_BITMAP);    // [5] // &ckpt->sit_nat_version_bitmap (or +offset); approx.
        if (!version_bitmap)
            return -EFAULT;
    
        /* copy version bitmap */
        memcpy(nm_i->nat_bitmap, version_bitmap, nm_i->bitmap_size); //[6]
        return f2fs_init_nid_bitmap(sbi);
    }
    

It’s important to note that most of the fields for generating the nat\_bitmap stored in the f2fs_nm_info object at \[3\] come from the f2fs_super_block at \[1\] and the f2fs_checkpoint at \[2\]. These structs are taken directly from the filesystem and are run through a good deal of checking after being read from disk. Keeping on, at \[4\], we can see the size of our nat bitmap be directly taken from our f2fs_checkpoint object, which is then malloc’ed. The source of the memcpy at \[6\] is generated from the __bitmap_ptr function at \[5\] which is as follows:

    static inline void *__bitmap_ptr(struct f2fs_sb_info *sbi, int flag)
    {
        struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi); // [1]
        int offset;
    
        if (is_set_ckpt_flags(ckpt, CP_LARGE_NAT_BITMAP_FLAG)) {
            // [...]
            return &ckpt->sit_nat_version_bitmap + offset + chksum_size;
        }
    
        if (le32_to_cpu(F2FS_RAW_SUPER(sbi)->cp_payload) > 0) { 
            if (flag == NAT_BITMAP)
                return &ckpt->sit_nat_version_bitmap;
            else
                return ((char *)ckpt + F2FS_BLKSIZE); // [2]
        } else {
            // [...]
            return &ckpt->sit_nat_version_bitmap + offset;  
        }
    }
    

The most important parts are shown above, we only really care about what the return value is. As shown, all possible code paths are offsets from the f2fs_checkpoint object at \[1\], which is the same f2fs_checkpoint talked about in the init_node_manager function. Furthermore, with the exception of \[2\], all return values also base from the sit_nat_version_bitmap member of our f2fs_checkpoint (offset +0xc0). The next step is to see exactly what this member is:

    int get_valid_checkpoint(struct f2fs_sb_info *sbi)   
    {  
        // [...]   
       cp_payload = get_sb(cp_payload);   // [1]  // vvv-(0x5)   
        if (cp_payload > F2FS_BLK_ALIGN(MAX_SIT_BITMAP_SIZE))   
            return -EINVAL;  
       
        cp_blks = 1 + cp_payload;  
        sbi->ckpt = malloc(cp_blks * blk_size);  // [2]   
      
        // [...]   
      
        if (cp_blks > 1) {   
            unsigned int i;  
            unsigned long long cp_blk_no;   
      
            cp_blk_no = get_sb(cp_blkaddr);   
            if (cur_page == cp2)  
                cp_blk_no += 1 << get_sb(log_blocks_per_seg);   
      
            /* copy sit bitmap */     
            for (i = 1; i < cp_blks; i++) {  
                unsigned char *ckpt = (unsigned char *)sbi->ckpt;    
                ret = dev_read_block(cur_page, cp_blk_no + i);   // [3]  
                ASSERT(ret >= 0);   
                memcpy(ckpt + i * blk_size, cur_page, blk_size); // [4]   
            }   
        }  
        //[...]   
    }  
    

At \[1\], the most important field for this function is read in, the cp_payload, which comes directly from the f2fs_superblock and the underlying disk. There is a check on it right below, the so the max cp_payload size is 0x5. The f2fs_checkpoint object mentioned before is actually malloc’ed at \[2\], in the total size being cp_blks \* 0x1000. Thus, the only sizes we can have for our f2fs_checkpoint object are 0x1000, 0x2000, 0x3000, 0x4000, and 0x5000. The contents are read in from the blocks directly after the f2fs_checkpoint at \[3\], and then copied to our malloc’ed buffer at \[4\]. Looking at the actual f2fs_checkpoint struct now:

    struct f2fs_checkpoint {   
        __le64 checkpoint_ver;      /* checkpoint block version number */  
        __le64 user_block_count;    /* # of user blocks */   
        __le64 valid_block_count;   /* # of valid blocks in main area */  
        __le32 rsvd_segment_count;  /* # of reserved segments for gc */   
        __le32 overprov_segment_count;  /* # of overprovision segments */  
        __le32 free_segment_count;  /* # of free segments in main area */   
      
        /* information of current node segments */   
        __le32 cur_node_segno[MAX_ACTIVE_NODE_LOGS];  
        __le16 cur_node_blkoff[MAX_ACTIVE_NODE_LOGS];   
        /* information of current data segments */  
        __le32 cur_data_segno[MAX_ACTIVE_DATA_LOGS];   
        __le16 cur_data_blkoff[MAX_ACTIVE_DATA_LOGS];  
        __le32 ckpt_flags;      /* Flags : umount and journal_present */   
        __le32 cp_pack_total_block_count;   /* total # of one cp pack */  
        __le32 cp_pack_start_sum;   /* start block number of data summary */   
        __le32 valid_node_count;    /* Total number of valid nodes */  
        __le32 valid_inode_count;   /* Total number of valid inodes */   
        __le32 next_free_nid;       /* Next free node number */  
        __le32 sit_ver_bitmap_bytesize; /* Default value 64 */   
        __le32 nat_ver_bitmap_bytesize; /* Default value 256 */  // [1] 
        __le32 checksum_offset;     /* checksum offset inside cp block */   
        __le64 elapsed_time;        /* mounted time */  
        /* allocation type of current segment */   
        unsigned char alloc_type[MAX_ACTIVE_LOGS];  
       
        /* SIT and NAT version bitmap */  
        unsigned char sit_nat_version_bitmap[1];  // [2] 
    } __attribute__((packed));  
      
    [o.O]> p/x sizeof(struct f2fs_checkpoint)   
    $3 = 0xc1  
    

The only things that really matter are \[1\] the size of the nat bitmap nat_ver_bitmap_size, and the sit_nat_version_bitmap at \[2\], since if readers will recall, those were the members used during the initialization of the node manager. Coming full circle:

    int init_node_manager(struct f2fs_sb_info *sbi){
        // [...]
    
        nm_i->bitmap_size = __bitmap_size(sbi, NAT_BITMAP); // [1] // le32_to_cpu(ckpt->nat_ver_bitmap_bytesize);
                                
        nm_i->nat_bitmap = malloc(nm_i->bitmap_size);
        if (!nm_i->nat_bitmap)
            return -ENOMkEM;
        version_bitmap = __bitmap_ptr(sbi, NAT_BITMAP);    // [2] // &ckpt->sit_nat_version_bitmap (or +offset); approx.
        if (!version_bitmap)
            return -EFAULT;
    
        /* copy version bitmap */
        memcpy(nm_i->nat_bitmap, version_bitmap, nm_i->bitmap_size); //[3]
        return f2fs_init_nid_bitmap(sbi);
    

To populate the nm_i->nat_bitmap at \[3\], the size utilized comes directly from ckpt->nat_ver_bitmap_bytesize at \[1\]. Also important to reiterate, the pointer at \[2\] that we read from corresponds directly with the 0x1000-0x5000 size chunk allocated within get_valid_checkpoint. So now the question becomes, where does the ckpt->nat_ver_bitmap_bytesize come from and what constraints does it have? As shown by “cscope”, there’s not really that many mentions in the first place:

    Text string: nat_ver_bitmap_bytesize
    
      File          Line
    0 f2fs.h         340 return le32_to_cpu(ckpt->nat_ver_bitmap_bytesize);
    1 f2fs.h         361 le32_to_cpu(ckpt->nat_ver_bitmap_bytesize) : 0;
    2 mount.c        388 DISP_u32(cp, nat_ver_bitmap_bytesize);
    3 mount.c       1157 nat_bitmap_size = get_cp(nat_ver_bitmap_bytesize);
    4 mount.c       1473 nm_i->bitmap_size = __bitmap_size(sbi, NAT_BITMAP); //  le32_to_cpu(ckpt->nat_ver_bitmap_bytesize);
    

Looking through all the above examples, the only real validation on the nat_bitmap_size field is appropriately in the sanity_check_ckpt function:

    int sanity_check_ckpt(struct f2fs_sb_info *sbi){   
    
        sit_segs = get_sb(segment_count_sit);
        fsmeta += sit_segs;
        nat_segs = get_sb(segment_count_nat); // [1]
        fsmeta += nat_segs;
    
        // [...]   
       
        sit_bitmap_size = get_cp(sit_ver_bitmap_bytesize);  
        nat_bitmap_size = get_cp(nat_ver_bitmap_bytesize);   
      
        if (sit_bitmap_size != ((sit_segs / 2) << log_blocks_per_seg) / 8 ||   
            nat_bitmap_size != ((nat_segs / 2) << log_blocks_per_seg) / 8) {   //[2] 
            MSG(0, "\tWrong bitmap size: sit(%u), nat(%u)\n",   
                    sit_bitmap_size, nat_bitmap_size);  
            return 1;   
        }  
       
    [...]  
    

So in the end, the only real checking \[2\] is to make sure that the sit_ver_bitmap_bytesize corresponds correctly to the superblock’s segment_count_nat member at \[1\]. Next we examine the segment_count_nat field for its constraints:

    static inline int sanity_check_area_boundary(struct f2fs_super_block *sb, enum SB_ADDR sb_addr) {   
      
        // [...]   
      
        if (sit_blkaddr + (segment_count_sit << log_blocks_per_seg) !=  nat_blkaddr) {  // [1]   
            MSG(0, "\tWrong SIT boundary, start(%u) end(%u) blocks(%u)\n",  
                sit_blkaddr, nat_blkaddr,   
                segment_count_sit << log_blocks_per_seg);  
            return -1;   
        }  
       
        if (nat_blkaddr + (segment_count_nat << log_blocks_per_seg) != ssa_blkaddr) {  // [2]  
            MSG(0, "\tWrong NAT boundary, start(%u) end(%u) blocks(%u)\n",   
                nat_blkaddr, ssa_blkaddr,  
                segment_count_nat << log_blocks_per_seg);   
            return -1;  
        }   
      
        // [...]   
    

At \[1\], we can see there’s one check to make sure that the previous SIT section lines up with our nat section, and at \[2\], we can see that the end of the nat section is also checked to see if it’s lined up correctly against the SSA section. Aside from that, there’s no check on the size of the NAT segment itself. Back to init_node_manager for emphasis:

    int init_node_manager(struct f2fs_sb_info *sbi){   
        // [...]  
       
        nm_i->bitmap_size = __bitmap_size(sbi, NAT_BITMAP); // [1] // le32_to_cpu(ckpt->nat_ver_bitmap_bytesize);  
                                   
        nm_i->nat_bitmap = malloc(nm_i->bitmap_size);  
        if (!nm_i->nat_bitmap)   
            return -ENOMkEM;  
        version_bitmap = __bitmap_ptr(sbi, NAT_BITMAP);    // [2] // &ckpt->sit_nat_version_bitmap (or +offset); approx.   
        if (!version_bitmap)  
            return -EFAULT;   
      
        /* copy version bitmap */   
        memcpy(nm_i->nat_bitmap, version_bitmap, nm_i->bitmap_size); //[3]  
        return f2fs_init_nid_bitmap(sbi);   
    

Since the nm_i->bitmap_size variable \[1\] is not really meaningfully limited in magnitude, and also since we know the size of our version_bitmap heap chunk \[2\] as 0x1000,0x2000,0x3000,0x4000, or 0x5000, the out of bounds heap read at \[3\] becomes apparent, allowing us to propagate our nm_i->nat_bitmap field with out of bounds heap data for further use.

Additional note on the exploitation on Android:  
In Google Pixel 3 running Android 10, the f2fs filesystem is used for the /data partition, and, due to the fstab configuration, f2fs.fsck is is always executed on boot on the /data partition. Moreover, since full-disk encryption has been deprecated in favor of file-based encryption, it is possible to corrupt metadata in a reproducible manner. This means that a vulnerability in f2fs.fsck would allow an attacker to gain privileges in its context during boot, which could be the first step to start a chain to maintain persistence on the device, bypassing Android verified boot. Such an attack would require either physical access to the Android device, or a temporary root access in a context that allows to write to block devices from the Android OS.

**Crash Information**

Program received signal SIGSEGV, Segmentation fault. 0x00007f6eda62206f in ?? () from /lib/x86\_64-linux-gnu/libc.so.6

    [^_^] SIGSEGV
    
    ***********************************************************************************
    ***********************************************************************************
    rax        : 0x7f6ed9a76010          | r13[S]     : 0x7ffc94046b70
    rbx        : 0x0                                  | r14        : 0x0
    rcx        : 0x102490                       | r15        : 0x0
    rdx        : 0x1200c0                       | rip[L]     : 0x7f6eda62206f
    rsi[H]     : 0x5581585f3000         | eflags     : 0x10202
    rdi        : 0x7f6ed9a93c40           | cs         : 0x33
    rbp[S]     : 0x7ffc940468c0         | ss         : 0x2b
    rsp[S]     : 0x7ffc94046868         | ds         : 0x0
    r8         : 0xffffffffffffffff              | es         : 0x0
    r9         : 0x5581586f5490          | fs         : 0x0
    r10        : 0x22                               | gs         : 0x0
    r11        : 0x9                                 | fs_base    : 0x7f6edb2fa840
    r12        : 0x558157cc7800    (_start) | gs_base    : 0x0
    ***********************************************************************************
    0x7f6eda62205f : lea    r9,[rsi+rdx*1]
    0x7f6eda622063 : cmp    rdi,r9
    0x7f6eda622066 : jb     0x7f6eda622231
    0x7f6eda62206c : mov    rcx,rdx
    =>0x7f6eda62206f : rep movs BYTE PTR es:[rdi],BYTE PTR ds:[rsi]
    0x7f6eda622071 : ret
    0x7f6eda622072 : cmp    dl,0x10
    0x7f6eda622075 : jae    0x7f6eda62208e
    0x7f6eda622077 : cmp    dl,0x8
    0x7f6eda62207a : jae    0x7f6eda6220a3
    ***********************************************************************************
    #0 0x00007f6eda62206f: in memcpy (0x7f6eda4f9000 0x7f6eda68e000 0x195000 0x0 /lib/x86_64-linux-gnu/libc-2.24.so)
    #1  0x0000558157cdb6b6 in init_node_manager (sbi=0x558157efcd60 <gfsck>) at mount.c:1483
    #2  0x0000558157cdb705 in build_node_manager (sbi=0x558157efcd60 <gfsck>) at mount.c:1494
    #3  0x0000558157ce0ce6 in f2fs_do_mount (sbi=0x558157efcd60 <gfsck>) at mount.c:3317
    #4  0x0000558157cc9c61 in main (argc=3, argv=0x7ffc94046b78) at main.c:800
    ***********************************************************************************
    
    [o.o]> x/10gx 0x5581585f3000
    0x5581585f3000: Cannot access memory at address 0x5581585f3000
    

**Timeline**

2020-05-08 - Vendor Disclosure  
2020-07-02 - 60 day follow up  
2020-07-20 - 90 day follow up  
2020-10-14 - Zero day public release

CVE-2020-6106: TALOS-2020-1048 || Cisco Talos Intelligence Group

An exploitable information disclosure vulnerability exists in the get_dnode_of_data functionality of F2fs-Tools F2fs.Fsck 1.13. A specially crafted f2fs filesystem can cause information disclosure resulting in a information disclosure. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2020-6104: TALOS-2020-1046 || Cisco Talos Intelligence Group

An exploitable code execution vulnerability exists in the multiple devices functionality of F2fs-Tools F2fs.Fsck 1.13. A specially crafted f2fs filesystem can cause Information overwrite resulting in a code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

An exploitable code execution vulnerability exists in the multiple devices functionality of F2fs-Tools F2fs.Fsck 1.13. A specially crafted f2fs filesystem can cause Information overwrite resulting in a code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

F2fs-Tools F2fs.Fsck 1.13

**Product URLs**

https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git

**CVSSv3 Score**

8.2 - CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-73 - External Control of File Name or Path

**Details**

The f2fs-tools set of utilities is used specifically for creating, checking and fixing f2fs (Flash-Friendly File System) files, a file system that has been replacing ext4 more recently in embedded devices, as it was crafted with eMMC chips and sdcards in mind. Fsck.f2fs more specifically is the file-system checking binary for f2fs partitions, and is where this vulnerability lies.

First it should be noted that the following vulnerability is completely an intended feature of f2fs in general. It’s not entirely clear why this f2fs feature exists in the first place, but there are inherent risks within it, as will be explained. First, let us explore the feature. The quickest way to explain it is to examine the output of f2fs.fsck on a sample file:

    Info: superblock features = 481 :  encrypt verity quota_ino
    Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
    Info: Device[0] : ./sample_f2fs.bin.patched blkaddr = 0--ce4dff  // [0]
    Info: Device[1] : /proc/self/mem blkaddr = ce4e00--100ce2fff     // [1]
    Info: total FS sectors = 108167128 (52815 MB)
    

A given F2fs filesystem can define up to eight different files that act as a backing to writes and reads for blocks. As shown above, for my given f2fs partition, two devices have been defined, ./sample_f2fs.bin.patched at \[0\] and /proc/self/mem at \[1\]. Astute readers will note that /proc/self/mem isn’t really a file that a program should be accessing, but moving on to where and why this occurs, let us examine the f2fs_super_block struct first:

    struct f2fs_super_block {
        __le32 magic;           /* Magic Number */
        __le16 major_ver;       /* Major Version */
        __le16 minor_ver;       /* Minor Version */
        __le32 log_sectorsize;      /* log2 sector size in bytes */
        __le32 log_sectors_per_block;   /* log2 # of sectors per block */
        __le32 log_blocksize;       /* log2 block size in bytes */
        __le32 log_blocks_per_seg;  /* log2 # of blocks per segment */
        __le32 segs_per_sec;        /* # of segments per section */
        __le32 secs_per_zone;       /* # of sections per zone */
        __le32 checksum_offset;     /* checksum offset inside super block */
        __le64 block_count;     /* total # of user blocks */
        __le32 section_count;       /* total # of sections */
        __le32 segment_count;       /* total # of segments */
        __le32 segment_count_ckpt;  /* # of segments for checkpoint */
        __le32 segment_count_sit;   /* # of segments for SIT */
        __le32 segment_count_nat;   /* # of segments for NAT */
        __le32 segment_count_ssa;   /* # of segments for SSA */
        __le32 segment_count_main;  /* # of segments for main area */
        __le32 segment0_blkaddr;    /* start block address of segment 0 */
        __le32 cp_blkaddr;      /* start block address of checkpoint */
        __le32 sit_blkaddr;     /* start block address of SIT */
        __le32 nat_blkaddr;     /* start block address of NAT */
        __le32 ssa_blkaddr;     /* start block address of SSA */
        __le32 main_blkaddr;        /* start block address of main area */
        __le32 root_ino;        /* root inode number */
        __le32 node_ino;        /* node inode number */
        __le32 meta_ino;        /* meta inode number */
        __u8 uuid[16];          /* 128-bit uuid for volume */
        __le16 volume_name[MAX_VOLUME_NAME];    /* volume name */
        __le32 extension_count;     /* # of extensions below */
        __u8 extension_list[F2FS_MAX_EXTENSION][8]; /* extension array */
        __le32 cp_payload;
        __u8 version[VERSION_LEN];  /* the kernel version */
        __u8 init_version[VERSION_LEN]; /* the initial kernel version */
        __le32 feature;         /* defined features */
        __u8 encryption_level;      /* versioning level for encryption */
        __u8 encrypt_pw_salt[16];   /* Salt used for string2key algorithm */
        struct f2fs_device devs[MAX_DEVICES];   /* device list */
        __le32 qf_ino[F2FS_MAX_QUOTAS]; /* quota inode numbers */
        __u8 hot_ext_count;     /* # of hot file extension */
        __le16  s_encoding;     /* Filename charset encoding */
        __le16  s_encoding_flags;   /* Filename charset encoding flags */
        __u8 reserved[306];     /* valid reserved region */
        __le32 crc;         /* checksum of superblock */
    } __attribute__((packed));
    

Taking out the definitions and information we actually care about:

    struct f2fs_super_block {
        //[...]
        struct f2fs_device devs[MAX_DEVICES];   /* device list */
        //[...]
    }
    
    #pragma pack(push, 1)
    struct f2fs_device {
        __u8 path[MAX_PATH_LEN];
        __le32 total_segments;
    } __attribute__((packed));
    
    #define MAX_PATH_LEN   64
    #define MAX_DEVICES     8
    

To clarify, the f2fs_super_block object has an array of eight f2fs_device structs in it, each one being 0x44 bytes in length. The first 0x40 bytes determine the path of the backing device, and the last __le32 member total_segments determines exactly which blocks the device backs. Let us examine the example output from above, and the f2fs partition that caused it:

    Info: superblock features = 481 :  encrypt verity quota_ino
    Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
    Info: Device[0] : ./sample_f2fs.bin.patched blkaddr = 0--ce4dff  
    Info: Device[1] : /proc/self/mem blkaddr = ce4e00--100ce2fff   [0] 
    Info: total FS sectors = 108167128 (52815 MB)
    
    # Current Layout =>
    00000C90   00 00 00 00  00 00 00 00  00 2E 2F 73  61 6D 70 6C  ........../sampl [1]
    00000CA0   65 5F 66 32  66 73 2E 62  69 6E 2E 70  61 74 63 68  e_f2fs.bin.patch
    00000CB0   65 64 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ed..............
    00000CC0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
    #                      segment count== 0x6726  V[2]
    00000CD0   00 00 00 00  00 00 00 00  00 26 67 00  00 2F 70 72  ............./pr 
    00000CE0   6F 63 2F 73  65 6C 66 2F  6D 65 6D 00  00 00 00 00  oc/self/mem.....
    00000CF0   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
    00000D00   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
    00000D10   00 00 00 00  00 00 00 00  00 00 00 00  00 F1 FF FF  ................
    00000D20   FF 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
    
    [>_>]> p/x offsetof(struct f2fs_super_block, devs)
    $3 = 0x899
    

Assuming the first superblock is valid, we start from offset 0x400 within the f2fs partition (otherwise 0x1400). Thus, our devs array starts at offset 0xc99 as shown above at \[1\]. At \[2\], we say that the first device ./sample_f2fs.bin.patched covers 0x6726 segments, which results in 0xce4d00 blocks total (as shown in the output). The next device we define is backed by /proc/self/mem (or any other file we choose), and we say that it backs all the rest of the blocks, hence the output at \[2\]. Stopping now, there’s not really a point in looking too deep into the init_sb_info function, but since it does read these devices off of disk and into memory, it’s worth showing:

    int init_sb_info(struct f2fs_sb_info *sbi)   
    {  
        struct f2fs_super_block *sb = F2FS_RAW_SUPER(sbi);   
        //[...]  
                        // 0x8   
        for (i = 0; i < MAX_DEVICES; i++) {  
            if (!sb->devs[i].path[0])   // [0]   
                break;  
       
            if (i) {  
                c.devices[i].path = strdup((char *)sb->devs[i].path); // [1]   
                if (get_device_info(i))                               // [2]  
                    ASSERT(0);   
            } else {  
                ASSERT(!strcmp((char *)sb->devs[i].path,   
                            (char *)c.devices[i].path));  
            }   
      
            c.devices[i].total_segments = le32_to_cpu(sb->devs[i].total_segments); // [3]   
      
            if (i){   
                c.devices[i].start_blkaddr = c.devices[i - 1].end_blkaddr + 1;  
            }   
            c.devices[i].end_blkaddr = c.devices[i].start_blkaddr +   // [3]
                c.devices[i].total_segments * c.blks_per_seg - 1;   
      
            if (i == 0)   
                c.devices[i].end_blkaddr += get_sb(segment0_blkaddr);  
       
            c.ndevs = i + 1;  
            MSG(0, "Info: Device[%d] : %s blkaddr = %"PRIx64"--%"PRIx64"\n",   
                    i, c.devices[i].path,  
                    c.devices[i].start_blkaddr,   
                    c.devices[i].end_blkaddr);  
        }   
     
    //[...]  
    

At \[1\], there’s a strdup from the device into memory, which is actually another bug if one strcpy’s eight devices and the last member has no null bytes (since there’s an oob read), however it’s a pretty useless bug and not really worth noting. At \[2\], we see the validation that occurs on the filename, which essentially boils down to a stat64 on the filename. At \[3\], the actual block definitions occur, one device begins where the previous one ends, etc.

Stepping back, what are the implications of this all? What does it mean for a specific block to be backed by a specific file? The best place to look would be the dev_read_block and dev_write_block functions:

    int dev_read_block(void *buf, __u64 blk_addr) {
        return dev_read(buf, blk_addr << F2FS_BLKSIZE_BITS, F2FS_BLKSIZE);
    }
    
    int dev_write_block(void *buf, __u64 blk_addr) {
        return dev_write(buf, blk_addr << F2FS_BLKSIZE_BITS, F2FS_BLKSIZE);
    }
    

It’s important to note that all reads from disk to memory and all writes from memory to disk occur in F2FS_BLKSIZE chunks (0x1000), and as such, all reads and writes done by f2fs.fsck happen with these two functions. Now let us examine the inner functions, dev_write and dev_read:

    int dev_read(void *buf, __u64 offset, size_t len)
    {
        int fd;
        //[...] 
     
        fd = __get_device_fd(&offset);
        if (fd < 0)
            return fd;
     
        if (lseek64(fd, (off64_t)offset, SEEK_SET) < 0)
            return -1;
        if (read(fd, buf, len) < 0)
            return -1;
        return 0;
    }
    
    
    int dev_write(void *buf, __u64 offset, size_t len)
    {
        int fd;
        //[...] 
     
        fd = __get_device_fd(&offset); // [1]
        if (fd < 0)
            return fd;
     
        if (lseek64(fd, (off64_t)offset, SEEK_SET) < 0) // [2]
            return -1;
        if (write(fd, buf, len) < 0) // [3]
            return -1;
        return 0;
    }
    

As shown, they’re essentially the same, with the sole difference being a write syscall versus a read syscall. At \[1\], an offset is found that we will examine soon, and at \[2\], we lseek to that offset. It should be noted that for the linux kernel, it doesn’t seem like lseek can fail, no matter the offset given, while with the android kernel, lseek can return -1 if given a big enough value. Moving on to \[3\], either the read or the write occurs at the given offset provided. Looking at __get_device_fd:

    static int __get_device_fd(__u64 *offset)
    {
        __u64 blk_addr = *offset >> F2FS_BLKSIZE_BITS;       // [1]
        int i;
     
        for (i = 0; i < c.ndevs; i++) {                      // [2]
            if (c.devices[i].start_blkaddr <= blk_addr &&
                    c.devices[i].end_blkaddr >= blk_addr) {
                *offset -= c.devices[i].start_blkaddr << F2FS_BLKSIZE_BITS;  // [3]
    
                return c.devices[i].fd;  // [4] 
            }
        }                     
        return -1;
    }
    

At \[1\], the offset we provide is shifted by 0xC bits, thus transforming it to which block we care about (i.e. offset 0x1123000 -> 0x1123). At \[2\], we iterate over all eight of our f2fs partition’s devices, and if the block number falls within the boundaries of a given device, we return that file descriptor at \[4\]. Also of interest is \[3\], since the input offset gets transformed once again, and is turned into an offset from the beginning of the device which backs a given block. To make clearer, looking again at our example layout:

    Info: Device[0] : ./sample_f2fs.bin.patched blkaddr = 0--ce4dff  
    Info: Device[1] : /proc/self/mem blkaddr = ce4e00--100ce2fff  
    

If we have a read on address 0xce4e01000, the offset would shift over 0xc bits, resulting in a read from block 0xce4e01, which falls in the block range for the /proc/self/mem device. We then subtract the start block of /proc/self/mem, which results in us reading the first block (0xce4e01-0xce4e00 => 0x1), which then shifts back 0xC bits to tell us to seek to offset 0x1000 within /proc/self/mem. The resulting seek might succeed depending on the underlying kernel, but the read will assuredly fail, resulting in a assert probably being triggered.

Assuming that we have a way around ASLR, it could be possible to define a filesystem that can read and write to its own address space successfully via this method. Since f2fs.fsck uses the read and write syscalls, the program does not crash if it tries to read or write from unmapped memory within /proc/self/mem, however (with one exception) all calls to dev_read_block and dev_write_block are wrapped with assert calls to make sure the reads and writes succeed. An alternative exploitation method would be to just define an arbitrary other file on the filesystem to be read and written to. The file must be at least 0x1000 in size in order to succeed, but it becomes possible to alter other filesystems than the f2fs partition on fs-check.

Additional note on the exploitation on Android:  
In Google Pixel 3 running Android 10, the f2fs filesystem is used for the /data partition, and, due to the fstab configuration, f2fs.fsck is is always executed on boot on the /data partition. Moreover, since full-disk encryption has been deprecated in favor of file-based encryption, it is possible to corrupt metadata in a reproducible manner. This means that a vulnerability in f2fs.fsck would allow an attacker to gain privileges in its context during boot, which could be the first step to start a chain to maintain persistence on the device, bypassing Android verified boot. Such an attack would require either physical access to the Android device, or a temporary root access in a context that allows to write to block devices from the Android OS.

**Timeline**

2020-05-08 - Vendor Disclosure  
2020-07-02 - 60 day follow up  
2020-07-20 - 90 day follow up  
2020-10-14 - Zero day public release

None - Public Release

CVE-2020-6105: TALOS-2020-1047 || Cisco Talos Intelligence Group

CodeLathe FileCloud before 20.2.0.11915 allows username enumeration.

CVE-2020-26524: FileCloud Release Notes

U.S. Air Force Sensor Data Management System extract75 has a buffer overflow that leads to code execution. An overflow in a global variable (sBuffer) leads to a Write-What-Where outcome. Writing beyond sBuffer will clobber most global variables until reaching a pointer such as DES_info or image_info. By controlling that pointer, one achieves an arbitrary write when its fields are assigned. The data written is from a potentially untrusted NITF file in the form of an integer. The attacker can gain control of the instruction pointer.

While fuzzing a NITF Extract utility extract75 utility published by the US Air Force Sensor Data Management System, we found a global buffer overflow that leads to a write-what-where condition. This flaw has been assigned CVE-2020-13995 and is disclosed in this blog post.

See our Coordinated Vulnerability Disclosure process for more information on how we go about disclosing vulnerabilities we find.

**Background**

The National Imagery Transmission Format (NITF) was the subject of our research as described in our blog post Suggested Updates to the National Imagery Transmission Format (NITF) Specification. While collecting public file format samples, we came across the Air Force Research Lab’s (AFRL) Sensor Data Management Systems website. This website hosts datasets as well as utilities for dealing with the associated formats.

The NITF Extract utility version 7.5 (extract75) is used for dumping NITF file information and was published1 by the US Air Force Sensor Data Management System and handles National Imagery Transmission Format (NITF) data. As was described on their page, “\[t\]his parser tool takes a NITF 2.0/2.1 file as input and outputs the JPEG file (if included), the data/image file and the metadata in flat files.”

**Issue**

An overflow in a global variable (sBuffer) leads to a Write-What-Where vulnerability. Writing beyond sBuffer will clobber most global variables until reaching a pointer DES_info. By controlling that pointer, there is an arbitrary write when its fields are assigned. The data written is from the file in the form of a 9 digit integer. In the PoC, by targeting strncpy we gain control of the instruction pointer.

Note that there are multiple similar bugs in the code, and if we switched to the image_info overflow we could likely write 10 bytes instead of 9. One could also likely get more range by using a negative number. See below for more details.

**Impact**

When the software parses a specially crafted NITF file, this vulnerability causes controlled memory corruption. The primary purpose of the software is to parse NITF input files. As such, using this software on untrusted input could lead to memory corruption, and potentially arbitrary code execution, on the target system.

This software is hosted by the United States Air Force and presumably used by the US military and other agencies. According to Wikipedia, “National Imagery Transmission Format Standard (NITFS) is a U.S. Department of Defense (DoD) and Federal Intelligence Community (IC) suite of standards for the exchange, storage, and transmission of digital-imagery products and image-related products.”2

**Vendor Response**

We contacted the US Air Force team who hosted the software. They promptly acknowledged the report and stated that they removed3 the download of the tool from their website to prevent further distribution three days after receipt of the initial notice.

As of July 31, 2020, the vendor stated that they have someone analyzing the problem, but have not decided on the remedy, and as such cannot currently provide an estimated patch date. River Loop remains willing to help discus remedies and confirm a patch if desired.

**What Users Can Do to Protect Themselves**

*   Until a patch is implemented, use a non-vulnerable NITF parser and cease use of extract75.
*   Be careful when opening NITF files, especially those from sources that may not be fully trusted, or which may have been modified by another party.
*   Scan for NITF files to identify those where the count of these sections exceeds the associated number, as this will lead to an overflow of sBuffer.
    *   Image 60
    *   Symbol 100
    *   Graphic 100
    *   Label 142
    *   Text 111
    *   DES 76
    *   RES 90

**How to Reproduce**

We created a crafted input file as a proof-of-concept (PoC) and provided it to the software vendor to test. We are not releasing it online at this time, however groups who may need it to confirm the security of their systems may contact us to request it.

**Details on Finding the Bugs**

> NOTE: This section is a detailed technical walkthrough of discovering and exploiting the crash. If you are not interested in this type of walk-through, please click here to skip.

The extract75 utility is a native application written in C. Upon downloading the utility to analyze and reviewing the source code we realized it was written in the 90s without security in mind and would likely have numerous bugs. Rather than finding those bugs manually, we tossed the parser in AFLPlusPlus instead. Rather quickly, multiple crashes were discovered. Upon triage we realized that the majority of them came from the same vulnerable code being repeated for multiple sections of the format.

**Crash Analysis**

The crash is caused by a global variable overflow. The overflow allows writing over other global variables. Those variables can be used to achieve a write-what-where. We’ll dive into this crash specifically:

    Crash id000003,sig11,src000000,time134513+000017,opsplice,rep128.

The global variable sBuffer has a fixed size of 1000 bytes. The application reads NUMDES (which is the number of data extension segments, or DES) from the file header. Following that field, for each DES, there is a size of DES header and size of DES data which are 4 bytes and 9 bytes, respectively. The function read_verify is called reading 13 (the size of the two size fields) multiplied by NUMDES. Doing a little math we can see that any value greater than 76 will overflow sBuffer.

    char sBuffer[1000];
    // ...
    // NUMDES 000 to 999
    // Any NUMDES greater than 76 is OF
    read_verify(hNITF, sBuffer, 13 * number_of_DESs, // (LDSHn 4 + LDn 9) * NUMDES
                "Error reading header / image subheader data lengths");

Following that read, the bytes are parsed in a loop and written to a structure. The number_of_DESs variable as well as the DES_info pointer are overwritten in the BSS overflow. Controlling that pointer gives the write-what-where.

    // Clobber BSS
    // DES_info is over written
    // ...
    DES_info[x].length_of_subheader = atol(Gstr);

The original NUMDES is 328. The overflow causes it to be clobbered.

    (gdb) info reg ebx
    ebx            0x148               328

After overflow we see what value is held and can use that to locate the data being written in the overflow.

    (gdb) p/x number_of_DESs
    $3 = 0x3d632b1d

In the file our NUMDES value is contained at the offset 0x10ef.

                                                            vv
    000010e0  1d 3f 4a c8 28 a7 a7 5f  6a a3 b5 81 2c 30 4f 1d  |.?J.(.._j...,0O.|
    000010f0  2b 63 3d 88 c1 fe b5 71  8e 39 1d 48 fc ea 74 27  |+c=....q.9.H..t'|
              ^^ ^^ ^^

We will do the same for DES_info which is our “where”. This is at offset 0x135f.

    (gdb) p/x DES_info
    $4 = 0x8f7b0479c6a57acf
                                                            vv
    00001350  fe bc 54 c4 a9 1e 9f e7  d6 9d 83 d8 83 fe 7f cf  |..T.............|
    00001360  7a a5 c6 79 04 7b 8f fe  bd 68 8c 6e 43 91 80 79  |z..y.{...h.nC..y|
              ^^ ^^ ^^ ^^ ^^ ^^ ^^

We can write 4 ASCII base 10 digits into the long length_of_subheader (0000-9999 == 0x0-0x270f), then 9 ASCII base 10 digits into length_of_data (000000000-999999999 == 0x0-0x3b9ac9ff).

    typedef struct {
       long length_of_subheader;
       long length_of_data;
       bool bFile_written;
       char *pData;
    } segment_info_type;

> NOTE: There are actually 7 of these overflows with various size writes.
> 
>     image_info = (image_info_type *)
>          malloc(sizeof(image_info_type) * number_of_images);
>     // ...
>     strncpy(Gstr, temp, 6);
>     strncpy(Gstr, temp, 10);
>     
>     symbol_info = (segment_info_type *)
>          malloc(sizeof(segment_info_type) * number_of_symbols);
>     // ...
>     strncpy(Gstr, temp, 4);
>     strncpy(Gstr, temp, 6);
>     
>     graphics_info = (segment_info_type *)
>          malloc(sizeof(segment_info_type) * number_of_graphics);
>     // ...
>     strncpy(Gstr, temp, 4);
>     strncpy(Gstr, temp, 6);
>     
>     label_info = (segment_info_type *)
>          malloc(sizeof(segment_info_type) * number_of_labels);
>     // ...
>     strncpy(Gstr, temp, 4);
>     strncpy(Gstr, temp, 3);
>     
>     text_info = (segment_info_type *)
>          malloc(sizeof(segment_info_type) * number_of_text_files);
>     // ...
>     strncpy(Gstr, temp, 4);
>     strncpy(Gstr, temp, 5);
>     
>     DES_info = (segment_info_type *)
>          malloc(sizeof(segment_info_type) * number_of_DESs);
>     // ...
>     strncpy(Gstr, temp, 4);
>     strncpy(Gstr, temp, 9);
>     
>     res_info = (segment_info_type *)
>          malloc(sizeof(segment_info_type) * number_of_res);
>     // ...
>     strncpy(Gstr, temp, 4);
>     strncpy(Gstr, temp, 7);

**Controlling Program Counter**

To demonstrate the crash, we want to hijack our program counter (RIP). To do this we’ll take a look at the binary’s security features.

    $ ./checksec --file=../extract75
    RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
    Partial RELRO   No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   617) Symbols      No    0               11              ../linux_ancient/extract75

Partial RELRO tells us that the section .got.plt is overwritable, so that is what we will target. The function strncpy() is called within the loop so that trigger will be immediate.

The first part of our “what” that is being written is 4 digits and we’ve placed 8738 (0x2222) at that location. The second is immediate after and we’ve placed 143165576 (0x8888888) there.

                                                             0x2222-----vvvv!!!!!------
    00000b70  38 30 30 30 33 32 38 38  37 33 38 31 34 33 31 36  |8000328873814316|    |
    00000b80  35 35 37 36 38 30 30 30  33 32 38 30 32 35 38 30  |5576800032802580| 0x8888888
                                                                 !!!!_________________|

The WHERE is the address to strncpy at 0x647040 in .got.plt.

                                                            vv                    
    00001350  fe bc 54 c4 a9 1e 9f e7  d6 9d 83 d8 83 fe 7f 40  |..T............@|
    00001360  70 64 00 00 00 00 00 fe  bd 68 8c 6e 43 91 80 79  |pd.......h.nC..y|
              ^^ ^^ ^^

We then run the program with our crafted file.

    Program received signal SIGSEGV, Segmentation fault.
    0x0000000000002222 in ?? ()

We got the 4 digit number length_of_subheader. Let’s adjust “where” down 8 bytes so we’ll overwrite the previous entry then use the 9 digit length_of_data write to get this one. Now we should hit 14316557 (0x8888888).

                                                            vv
    00001350  fe bc 54 c4 a9 1e 9f e7  d6 9d 83 d8 83 fe 7f 38  |..T............8|
    00001360  70 64 00 00 00 00 00 fe  bd 68 8c 6e 43 91 80 79  |pd.......h.nC..y|
              ^^ ^^ ^^

Running it again:

    Program received signal SIGSEGV, Segmentation fault.
    0x0000000008888888 in ?? ()

If we switched to the image_info overflow we could get 10 bytes instead of 9. It is also likely that we could get a greater range by using a negative number, but we have not tested this. Given that there are 7 identical overflows it should be possible to craft a file that can take advantage of these flaws.

**Disclosure Timeline**

*   052020 - Achieved crash during use of automated fuzzing leveraging our customized minimized NITF feature coverage set
*   06042020 - Triaged crash and developed PoC exploit demonstrating control of IP
*   06052020 - Emailed sdms\_help@vdl.afrl.af.mil to ask how to report a vulnerability to them and shared our responsible disclosure policy. SDMS replied and said RLS can send directly to that alias with no other processes/protections.
*   06082020 - SDMS confirmed report received, that they are removing it from the public website until the vulnerability is fixed, and that they do not need other information at this time. RLS replied asking about preferred CNA and reminding of 60 day disclosure policy.
*   06092020 - RLS notes that SDMS has removed extract75 from the webpage. Prior URL https://www.sdms.afrl.af.mil/index.php?collection=tools\_nitf returns HTTP 404.
*   07022020 - RLS emails SDMS to check if any updates and if other help is needed. Notes that they should inspect for similar bug classes elsewhere in the code. Reminded of August 4, 2020 60 day disclosure date.
*   07272020 - RLS emails SDMS to check if any updates and to request information on mitigations, patch plans, or other information to include in the disclosure scheduled for NLT August 4.
*   07312020 - Vendor replies to state “We have someone analyzing the problem, but have not decided on the remedy as of this email. Therefore, I can not give you an estimated patch date.”
*   08042020 - Upon preparing this disclosure for publication, we learned that it was not fully removed from the site, and instead was moved to a different “hidden” URL of https://www.sdms.afrl.af.mil/index.php?collection=tools\_nitf\_hidden. This URL has been indexed by Google and is easily found. We notified SDMS of this.
*   082020 - Various scheduling attempts with the SDMS team, RLS offers multiple dates.
*   08202020 - RLS joined SDMS team on a conference call to discuss the vulnerability and provide context. SDMS team noted that the tool came about from a DARPA program in 1998, when they wrote the tool to handle parsing data. They do not actively maintain it, and it was intended to work on trusted data. RLS transmitted reproduction file again and SDMS confirmed reciept.
*   09242020 - Publication of this post and release of CVE.

**Credit**

Doug Gastonguay-Goddard of River Loop Security

**Conclusion**

We hope that this has given you a brief overview of this bug and that it helps users and developers of the NITF file format and tools secure systems better. You may also be interested in our blog post Suggested Updates to the National Imagery Transmission Format (NITF) Specification.

Specifying file formats in natural language leaves a lot of details open to interpretation by developers. Combining these ambiguities and human fallibility with memory-unsafe languages leads to dangerous flaws in the software we rely on. As researchers, our job beyond discovering flaws is to create systems for eliminating them (see our other posts for more details). If you have any questions or comments based on this post or would like to engage River Loop Security to audit file formats, specifications, or parsers please contact us.

Correction 3/24/2022: A correction was made to the line read_verify(hNITF, sBuffer, 13 * number_of_DESs, // (LDSHn 4 + LDn 9) * NUMDES based on reader input that the LDSHn and LDn values were incorrectly listed in this line.

CVE-2020-13995: CVE-2020-13995: Details on a Vulnerability in a NITF Parser

Pagure before 5.6 allows XSS via the templates/blame.html blame view.

CVE-2019-11556: Changelog — pagure documentation

Insufficient policy enforcement in installer in Google Chrome on OS X prior to 85.0.4183.102 allowed a local attacker to potentially achieve privilege escalation via a crafted binary.

CVE-2020-6574: Stable Channel Update for Desktop

Insufficient validation of untrusted input in command line handling in Google Chrome on Windows prior to 85.0.4183.83 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page.

CVE-2020-6567

Insufficient policy enforcement in autofill in Google Chrome prior to 85.0.4183.83 allowed a remote attacker to leak cross-origin data via a crafted HTML page.

**Chrome Releases**

Release updates from the Chrome team

CVE-2020-6560: Stable Channel Update for Desktop

Node.js < 14.11.0 is vulnerable to HTTP denial of service (DoS) attacks based on delayed requests submission which can make the server unable to accept new connections.

Updates are now available for v10,x, v12.x and v14.x Node.js release lines for the following issues.

Affected Node.js versions converted carriage returns in HTTP request headers to a hyphen before parsing. This can lead to HTTP Request Smuggling as it is a non-standard interpretation of the header.

Impacts:

*   All versions of the 14.x and 12.x releases line

Thank you to Amit Klein who works at Safebreach for reporting this vulnerability.

Node.js is vulnerable to HTTP denial of service (DOS) attacks based on delayed requests submission which can make the server unable to accept new connections. The fix a new http.Server option called requestTimeout with a default value of 0 which means it is disabled by default. This should be set when Node.js is used as an edge server, for more details refer to the documentation.

Impacts:

*   All versions of the 14.x release line

Thank you to Paolo Insogna and Matteo Collina who work at NearFom for reporting and fixing this vulnerability.

libuv's realpath implementation incorrectly determined the buffer size which can result in a buffer overflow if the resolved path is longer than 256 bytes.

Impacts:

*   All versions of the 10.x release line
*   All versions of the 12.x release line
*   All versions of the 14.x release line before 14.9.0

Thank you Xiaoyi Shi who works at Tencent for reporting this vulnerability.

**Downloads and release details**

*   Node.js v10.22.1 (LTS)
*   Node.js v12.18.4 (LTS)
*   Node.js v14.11.0 (Current)

The Node.js project will release new versions of all supported release lines on or shortly after Tuesday, September 15, 2020. These releases will fix

*   One critical severity issue
*   One high severity issue
*   One medium severity issue

The 14.x release line of Node.js is vulnerable to one critical severity issue, one high severity issue and one medium severity issue.

The 12.x release line of Node.js is vulnerable to one high severity issue, and one medium severity issue.

10.x release line of Node.js is vulnerable to one medium severity issue.

Releases will be available at, or shortly after, Tuesday, September 15th, 2020.

The current Node.js security policy can be found at https://github.com/nodejs/node/blob/HEAD/SECURITY.md#security. Please follow the process outlined in https://github.com/nodejs/node/blob/master/SECURITY.md if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organization.

Tag

#google