[fips-9-compliant] Many VULNs 20-09-25

[shreeya-patel98]

Background

VULN-8805 :-
The fix mentioned in this ticket was never applied to kernel.
[PATCH rdma-next] RDMA/core: Fix resolve_prepare_src error cleanup — Linux RDMA and InfiniBand development

Instead, another commit changed things completely for the module and then the above fix was no longer needed. RDMA/core: Refactor rdma_bind_addr · torvalds/linux@8d03797

So I have applied the latter one here.

Commits

    tee: amdtee: fix race condition in amdtee_open_session
    
    jira VULN-66921
    cve CVE-2023-53047
    commit-author Rijo Thomas <Rijo-john.Thomas@amd.com>
    commit f8502fba45bd30e1a6a354d9d898bc99d1a11e6d
    
    There is a potential race condition in amdtee_open_session that may
    lead to use-after-free. For instance, in amdtee_open_session() after
    sess->sess_mask is set, and before setting:
    
        sess->session_info[i] = session_info;
    
    if amdtee_close_session() closes this same session, then 'sess' data
    structure will be released, causing kernel panic when 'sess' is
    accessed within amdtee_open_session().
    
    The solution is to set the bit sess->sess_mask as the last step in
    amdtee_open_session().
    

    Squashfs: fix handling and sanity checking of xattr_ids count
    
    jira VULN-55077
    cve CVE-2023-52933
    commit-author Phillip Lougher <phillip@squashfs.org.uk>
    commit f65c4bbbd682b0877b669828b4e033b8d5d0a2dc
    
    A Sysbot [1] corrupted filesystem exposes two flaws in the handling and
    sanity checking of the xattr_ids count in the filesystem.  Both of these
    flaws cause computation overflow due to incorrect typing.
    
    In the corrupted filesystem the xattr_ids value is 4294967071, which
    stored in a signed variable becomes the negative number -225.
    
    Flaw 1 (64-bit systems only):
    
    The signed integer xattr_ids variable causes sign extension.
    
    This causes variable overflow in the SQUASHFS_XATTR_*(A) macros.  The
    variable is first multiplied by sizeof(struct squashfs_xattr_id) where the
    type of the sizeof operator is "unsigned long".
    
    On a 64-bit system this is 64-bits in size, and causes the negative number
    to be sign extended and widened to 64-bits and then become unsigned.  This
    produces the very large number 18446744073709548016 or 2^64 - 3600.  This
    number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and
    divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0
    (stored in len).
    
    Flaw 2 (32-bit systems only):
    
    On a 32-bit system the integer variable is not widened by the unsigned
    long type of the sizeof operator (32-bits), and the signedness of the
    variable has no effect due it always being treated as unsigned.
    
    The above corrupted xattr_ids value of 4294967071, when multiplied
    overflows and produces the number 4294963696 or 2^32 - 3400.  This number
    when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by
    SQUASHFS_METADATA_SIZE overflows again and produces a length of 0.
    
    The effect of the 0 length computation:
    
    In conjunction with the corrupted xattr_ids field, the filesystem also has
    a corrupted xattr_table_start value, where it matches the end of
    filesystem value of 850.
    
    This causes the following sanity check code to fail because the
    incorrectly computed len of 0 matches the incorrect size of the table
    reported by the superblock (0 bytes).
    
        len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids);
        indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids);
    
        /*
         * The computed size of the index table (len bytes) should exactly
         * match the table start and end points
        */
        start = table_start + sizeof(*id_table);
        end = msblk->bytes_used;
    
        if (len != (end - start))
                return ERR_PTR(-EINVAL);
    
    Changing the xattr_ids variable to be "usigned int" fixes the flaw on a
    64-bit system.  This relies on the fact the computation is widened by the
    unsigned long type of the sizeof operator.
    
    Casting the variable to u64 in the above macro fixes this flaw on a 32-bit
    system.
    
    It also means 64-bit systems do not implicitly rely on the type of the
    sizeof operator to widen the computation.
    
    [1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/
    

    Bluetooth: af_bluetooth: Fix deadlock
    
    jira VULN-37166
    cve CVE-2024-26886
    commit-author Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    commit f7b94bdc1ec107c92262716b073b3e816d4784fb
    
    Attemting to do sock_lock on .recvmsg may cause a deadlock as shown
    bellow, so instead of using sock_sock this uses sk_receive_queue.lock
    on bt_sock_ioctl to avoid the UAF:
    
    INFO: task kworker/u9:1:121 blocked for more than 30 seconds.
          Not tainted 6.7.6-lemon #183
    Workqueue: hci0 hci_rx_work
    Call Trace:
     <TASK>
     __schedule+0x37d/0xa00
     schedule+0x32/0xe0
     __lock_sock+0x68/0xa0
     ? __pfx_autoremove_wake_function+0x10/0x10
     lock_sock_nested+0x43/0x50
     l2cap_sock_recv_cb+0x21/0xa0
     l2cap_recv_frame+0x55b/0x30a0
     ? psi_task_switch+0xeb/0x270
     ? finish_task_switch.isra.0+0x93/0x2a0
     hci_rx_work+0x33a/0x3f0
     process_one_work+0x13a/0x2f0
     worker_thread+0x2f0/0x410
     ? __pfx_worker_thread+0x10/0x10
     kthread+0xe0/0x110
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x2c/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1b/0x30
     </TASK>

    Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg
    
    jira VULN-8866
    cve CVE-2023-51779
    commit-author Hyunwoo Kim <v4bel@theori.io>
    commit 2e07e8348ea454615e268222ae3fc240421be768
    
    This can cause a race with bt_sock_ioctl() because
    bt_sock_recvmsg() gets the skb from sk->sk_receive_queue
    and then frees it without holding lock_sock.
    A use-after-free for a skb occurs with the following flow.
    bt_sock_recvmsg() -> skb_recv_datagram() -> skb_free_datagram()
    bt_sock_ioctl() -> skb_peek()
    
    Add lock_sock to bt_sock_recvmsg() to fix this issue.
    

    drm/atomic: Fix potential use-after-free in nonblocking commits
    
    jira VULN-8862
    cve CVE-2023-51043
    commit-author Daniel Vetter <daniel.vetter@ffwll.ch>
    commit 4e076c73e4f6e90816b30fcd4a0d7ab365087255
    
    This requires a bit of background.  Properly done a modeset driver's
    unload/remove sequence should be
    
            drm_dev_unplug();
            drm_atomic_helper_shutdown();
            drm_dev_put();
    
    The trouble is that the drm_dev_unplugged() checks are by design racy,
    they do not synchronize against all outstanding ioctl.  This is because
    those ioctl could block forever (both for modeset and for driver
    specific ioctls), leading to deadlocks in hotunplug.  Instead the code
    sections that touch the hardware need to be annotated with
    drm_dev_enter/exit, to avoid accessing hardware resources after the
    unload/remove has finished.
    
    To avoid use-after-free issues all the involved userspace visible
    objects are supposed to hold a reference on the underlying drm_device,
    like drm_file does.
    
    The issue now is that we missed one, the atomic modeset ioctl can be run
    in a nonblocking fashion, and in that case it cannot rely on the implied
    drm_device reference provided by the ioctl calling context.  This can
    result in a use-after-free if an nonblocking atomic commit is carefully
    raced against a driver unload.
    
    Fix this by unconditionally grabbing a drm_device reference for any
    drm_atomic_state structures.  Strictly speaking this isn't required for
    blocking commits and TEST_ONLY calls, but it's the simpler approach.
    
    Thanks to shanzhulig for the initial idea of grabbing an unconditional
    reference, I just added comments, a condensed commit message and fixed a
    minor potential issue in where exactly we drop the final reference.
    

    netfilter: nf_tables: skip immediate deactivate in _PREPARE_ERROR
    
    jira VULN-8835
    cve CVE-2023-4015
    commit-author Pablo Neira Ayuso <pablo@netfilter.org>
    commit 0a771f7b266b02d262900c75f1e175c7fe76fec2
    
    On error when building the rule, the immediate expression unbinds the
    chain, hence objects can be deactivated by the transaction records.
    
    Otherwise, it is possible to trigger the following warning:
    
     WARNING: CPU: 3 PID: 915 at net/netfilter/nf_tables_api.c:2013 nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
     CPU: 3 PID: 915 Comm: chain-bind-err- Not tainted 6.1.39 #1
     RIP: 0010:nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
    

    vc_screen: modify vcs_size() handling in vcs_read()
    
    jira VULN-8820
    cve-bf CVE-2023-3567
    commit-author George Kennedy <george.kennedy@oracle.com>
    commit 46d733d0efc79bc8430d63b57ab88011806d5180
    
    Restore the vcs_size() handling in vcs_read() to what
    it had been in previous version.

    vc_screen: don't clobber return value in vcs_read
    
    jira VULN-8820
    cve-bf CVE-2023-3567
    commit-author Thomas Weißschuh <linux@weissschuh.net>
    commit ae3419fbac845b4d3f3a9fae4cc80c68d82cdf6e
    
    Commit 226fae124b2d ("vc_screen: move load of struct vc_data pointer in
    vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop.
    
    While doing this it also moved the unconditional assignment of
    
            ret = -ENXIO;
    
    This unconditional assignment was valid outside the loop but within it
    it clobbers the actual value of ret.
    
    To avoid this only assign "ret = -ENXIO" when actually needed.
    
    [ Also, the 'goto unlock_out" needs to be just a "break", so that it
      does the right thing when it exits on later iterations when partial
      success has happened - Linus ]

    vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF
    
    jira VULN-8820
    cve CVE-2023-3567
    commit-author George Kennedy <george.kennedy@oracle.com>
    commit 226fae124b2dac217ea5436060d623ff3385bc34
    
    After a call to console_unlock() in vcs_read() the vc_data struct can be
    freed by vc_deallocate(). Because of that, the struct vc_data pointer
    load must be done at the top of while loop in vcs_read() to avoid a UAF
    when vcs_size() is called.
    
    Syzkaller reported a UAF in vcs_size().
    
    BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)
    Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537
    
    CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1
    Hardware name: Red Hat KVM, BIOS 1.15.0-2.module
    Call Trace:
      <TASK>
    __asan_report_load4_noabort (mm/kasan/report_generic.c:350)
    vcs_size (drivers/tty/vt/vc_screen.c:215)
    vcs_read (drivers/tty/vt/vc_screen.c:415)
    vfs_read (fs/read_write.c:468 fs/read_write.c:450)
    ...
      </TASK>
    
    Allocated by task 1191:
    ...
    kmalloc_trace (mm/slab_common.c:1069)
    vc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720
         drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108)
    con_install (drivers/tty/vt/vt.c:3383)
    tty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413
         drivers/tty/tty_io.c:1390)
    tty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126)
    chrdev_open (fs/char_dev.c:415)
    do_dentry_open (fs/open.c:883)
    vfs_open (fs/open.c:1014)
    ...
    
    Freed by task 1548:
    ...
    kfree (mm/slab_common.c:1021)
    vc_port_destruct (drivers/tty/vt/vt.c:1094)
    tty_port_destructor (drivers/tty/tty_port.c:296)
    tty_port_put (drivers/tty/tty_port.c:312)
    vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))
    vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)
    tty_ioctl (drivers/tty/tty_io.c:2776)
    ...
    
    The buggy address belongs to the object at ffff888113747800
      which belongs to the cache kmalloc-1k of size 1024
    The buggy address is located 424 bytes inside of
      1024-byte region [ffff888113747800, ffff888113747c00)
    
    The buggy address belongs to the physical page:
    page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000
         index:0x0 pfn:0x113740
    head:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0
         compound_pincount:0
    anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
    raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001
    raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
      ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    > ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                       ^
      ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    Disabling lock debugging due to kernel taint
    

    RDMA/core: Update CMA destination address on rdma_resolve_addr
    
    jira VULN-8805
    cve-bf CVE-2023-2176
    commit-author Shiraz Saleem <shiraz.saleem@intel.com>
    commit 0e15863015d97c1ee2cc29d599abcc7fa2dc3e95
    
    8d037973d48c ("RDMA/core: Refactor rdma_bind_addr") intoduces as regression
    on irdma devices on certain tests which uses rdma CM, such as cmtime.
    
    No connections can be established with the MAD QP experiences a fatal
    error on the active side.
    
    The cma destination address is not updated with the dst_addr when ULP
    on active side calls rdma_bind_addr followed by rdma_resolve_addr.
    The id_priv state is 'bound' in resolve_prepare_src and update is skipped.
    
    This leaves the dgid passed into irdma driver to create an Address Handle
    (AH) for the MAD QP at 0. The create AH descriptor as well as the ARP cache
    entry is invalid and HW throws an asynchronous events as result.
    
    [ 1207.656888] resolve_prepare_src caller: ucma_resolve_addr+0xff/0x170 [rdma_ucm] daddr=200.0.4.28 id_priv->state=7
    [....]
    [ 1207.680362] ice 0000:07:00.1 rocep7s0f1: caller: irdma_create_ah+0x3e/0x70 [irdma] ah_id=0 arp_idx=0 dest_ip=0.0.0.0
    destMAC=00:00:64:ca:b7:52 ipvalid=1 raw=0000:0000:0000:0000:0000:ffff:0000:0000
    [ 1207.682077] ice 0000:07:00.1 rocep7s0f1: abnormal ae_id = 0x401 bool qp=1 qp_id = 1, ae_src=5
    [ 1207.691657] infiniband rocep7s0f1: Fatal error (1) on MAD QP (1)
    
    Fix this by updating the CMA destination address when the ULP calls
    a resolve address with the CM state already bound.

    RDMA/core: Refactor rdma_bind_addr
    
    jira VULN-8805
    cve CVE-2023-2176
    commit-author Patrisious Haddad <phaddad@nvidia.com>
    commit 8d037973d48c026224ab285e6a06985ccac6f7bf
    
    Refactor rdma_bind_addr function so that it doesn't require that the
    cma destination address be changed before calling it.
    
    So now it will update the destination address internally only when it is
    really needed and after passing all the required checks.
    
    Which in turn results in a cleaner and more sensible call and error
    handling flows for the functions that call it directly or indirectly.
    

    ovl: fix use after free in struct ovl_aio_req
    
    jira VULN-8795
    cve CVE-2023-1252
    commit-author yangerkun <yangerkun@huawei.com>
    commit 9a254403760041528bc8f69fe2f5e1ef86950991
    
    Example for triggering use after free in a overlay on ext4 setup:
    
    aio_read
      ovl_read_iter
        vfs_iter_read
          ext4_file_read_iter
            ext4_dio_read_iter
              iomap_dio_rw -> -EIOCBQUEUED
              /*
               * Here IO is completed in a separate thread,
               * ovl_aio_cleanup_handler() frees aio_req which has iocb embedded
               */
              file_accessed(iocb->ki_filp); /**BOOM**/
    
    Fix by introducing a refcount in ovl_aio_req similarly to aio_kiocb.  This
    guarantees that iocb is only freed after vfs_read/write_iter() returns on
    underlying fs.
    

    drivers: net: slip: fix NPD bug in sl_tx_timeout()
    
    jira VULN-8770
    cve CVE-2022-41858
    commit-author Duoming Zhou <duoming@zju.edu.cn>
    commit ec4eb8a86ade4d22633e1da2a7d85a846b7d1798
    
    When a slip driver is detaching, the slip_close() will act to
    cleanup necessary resources and sl->tty is set to NULL in
    slip_close(). Meanwhile, the packet we transmit is blocked,
    sl_tx_timeout() will be called. Although slip_close() and
    sl_tx_timeout() use sl->lock to synchronize, we don`t judge
    whether sl->tty equals to NULL in sl_tx_timeout() and the
    null pointer dereference bug will happen.
    
       (Thread 1)                 |      (Thread 2)
                                  | slip_close()
                                  |   spin_lock_bh(&sl->lock)
                                  |   ...
    ...                           |   sl->tty = NULL //(1)
    sl_tx_timeout()               |   spin_unlock_bh(&sl->lock)
      spin_lock(&sl->lock);       |
      ...                         |   ...
      tty_chars_in_buffer(sl->tty)|
        if (tty->ops->..) //(2)   |
        ...                       |   synchronize_rcu()
    
    We set NULL to sl->tty in position (1) and dereference sl->tty
    in position (2).
    
    This patch adds check in sl_tx_timeout(). If sl->tty equals to
    NULL, sl_tx_timeout() will goto out.
    

    nfp: fix use-after-free in area_cache_get()
    
    jira VULN-8758
    cve CVE-2022-3545
    commit-author Jialiang Wang <wangjialiang0806@163.com>
    commit 02e1a114fdb71e59ee6770294166c30d437bf86a
    
    area_cache_get() is used to distribute cache->area and set cache->id,
     and if cache->id is not 0 and cache->area->kref refcount is 0, it will
     release the cache->area by nfp_cpp_area_release(). area_cache_get()
     set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire().
    
    But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is
     is already set but the refcount is not increased as expected. At this
     time, calling the nfp_cpp_area_release() will cause use-after-free.
    
    To avoid the use-after-free, set cache->id after area_init() and
     nfp_cpp_area_acquire() complete successfully.
    
    Note: This vulnerability is triggerable by providing emulated device
     equipped with specified configuration.
    
     BUG: KASAN: use-after-free in nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760)
      Write of size 4 at addr ffff888005b7f4a0 by task swapper/0/1
    
     Call Trace:
      <TASK>
     nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760)
     area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:884)
    
     Allocated by task 1:
     nfp_cpp_area_alloc_with_name (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:303)
     nfp_cpp_area_cache_add (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:802)
     nfp6000_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:1230)
     nfp_cpp_from_operations (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:1215)
     nfp_pci_probe (drivers/net/ethernet/netronome/nfp/nfp_main.c:744)
    
     Freed by task 1:
     kfree (mm/slub.c:4562)
     area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:873)
     nfp_cpp_read (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:924 drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:973)
     nfp_cpp_readl (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpplib.c:48)
     

Kernel Build Log

/mnt/scratch/workspace/fips-9-compliant/kernel-src-tree
Skipping make mrproper
[TIMER]{MRPROPER}: 0s
x86_64 architecture detected, copying config
'configs/kernel-x86_64-rhel.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-shreeya_fips-9-compliant_5.14.0-284.30.1-88ef6b42321d"
Making olddefconfig
#
# configuration written to .config
#
Starting Build
 SYNC    include/config/auto.conf.cmd
 UPD     include/config/kernel.release
 DESCEND objtool
 DESCEND bpf/resolve_btfids
 UPD     include/generated/utsrelease.h
 CALL    scripts/atomic/check-atomics.sh
warning: generated include/linux/atomic/atomic-instrumented.h has been modified.
 CALL    scripts/checksyscalls.sh
 CHK     include/generated/compile.h
 CC      init/version.o
 CC      arch/x86/crypto/aesni-intel_glue.o
 AR      init/built-in.a
 CC      kernel/sys.o
 CC      crypto/fips.o
 AR      arch/x86/crypto/built-in.a
 CC      crypto/algapi.o
 CC      security/integrity/ima/ima_init.o
 AR      arch/x86/built-in.a
 <--snip-->
drivers/cxl/cxl_mem.ko
 STRIP   /lib/modules/5.14.0-shreeya_fips-9-compliant_5.14.0-284.30.1-88ef6b42321d+/kernel/drivers/cxl/cxl_mem.ko
 SIGN    /lib/modules/5.14.0-shreeya_fips-9-compliant_5.14.0-284.30.1-88ef6b42321d+/kernel/drivers/cxl/cxl_mem.ko
 DEPMOD  /lib/modules/5.14.0-shreeya_fips-9-compliant_5.14.0-284.30.1-88ef6b42321d+
[TIMER]{MODULES}: 9s
Making Install
sh ./arch/x86/boot/install.sh \
   5.14.0-shreeya_fips-9-compliant_5.14.0-284.30.1-88ef6b42321d+ arch/x86/boot/bzImage \
   System.map "/boot"
[TIMER]{INSTALL}: 20s
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-5.14.0-shreeya_fips-9-compliant_5.14.0-284.30.1-0ddad05ec4f4+ and Index to 4
The default is /boot/loader/entries/809410938d1447fc931cf787fb714082-5.14.0-shreeya_fips-9-compliant_5.14.0-284.30.1-0ddad05ec4f4+.conf with index 4 and kernel /boot/vmlinuz-5.14.0-shreeya_fips-9-compliant_5.14.0-284.30.1-0ddad05ec4f4+
The default is /boot/loader/entries/809410938d1447fc931cf787fb714082-5.14.0-shreeya_fips-9-compliant_5.14.0-284.30.1-0ddad05ec4f4+.conf with index 4 and kernel /boot/vmlinuz-5.14.0-shreeya_fips-9-compliant_5.14.0-284.30.1-0ddad05ec4f4+
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 0s
[TIMER]{BUILD}: 228s
[TIMER]{MODULES}: 9s
[TIMER]{INSTALL}: 20s
[TIMER]{TOTAL} 261s
Rebooting in 10 seconds

kernel-build.log

Testing

shreeya@spatel-dev-bom ~/c/w/fips-9-compliant> grep -a ^ok kselftest-before.log | wc -l
324
shreeya@spatel-dev-bom ~/c/w/fips-9-compliant> grep -a ^ok kselftest-after.log | wc -l
323

kselftest-after.log
kselftest-before.log

[github-actions]

🔍 Upstream Linux Kernel Commit Check

• ⚠️ PR commit 2e2e23cc2ed6 (RDMA/core: Refactor rdma_bind_addr) references upstream commit
  8d037973d48c which has been referenced by a Fixes: tag in the upstream
  Linux kernel:

    0e15863015d9 RDMA/core: Update CMA destination address on rdma_resolve_addr (Shiraz Saleem)

• ⚠️ PR commit 2b0d64688443 (vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF) references upstream commit
  226fae124b2d which has been referenced by a Fixes: tag in the upstream
  Linux kernel:

    ae3419fbac84 vc_screen: don't clobber return value in vcs_read (Thomas Weißschuh)
    46d733d0efc7 vc_screen: modify vcs_size() handling in vcs_read() (George Kennedy)

• ⚠️ PR commit 0fbf017d8a61 (Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg) references upstream commit
  2e07e8348ea4 which has been referenced by a Fixes: tag in the upstream
  Linux kernel:

    f7b94bdc1ec1 Bluetooth: af_bluetooth: Fix deadlock (Luiz Augusto von Dentz)

This is an automated message from the kernel commit checker workflow.

[github-actions]

🔍 Upstream Linux Kernel Commit Check

• ⚠️ PR commit 2e2e23cc2ed6 (RDMA/core: Refactor rdma_bind_addr) references upstream commit
  8d037973d48c which has been referenced by a Fixes: tag in the upstream
  Linux kernel:

    0e15863015d9 RDMA/core: Update CMA destination address on rdma_resolve_addr (Shiraz Saleem)

• ⚠️ PR commit dd036d0ce001 (vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF) references upstream commit
  226fae124b2d which has been referenced by a Fixes: tag in the upstream
  Linux kernel:

    ae3419fbac84 vc_screen: don't clobber return value in vcs_read (Thomas Weißschuh)
    46d733d0efc7 vc_screen: modify vcs_size() handling in vcs_read() (George Kennedy)

• ⚠️ PR commit 776f12860485 (Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg) references upstream commit
  2e07e8348ea4 which has been referenced by a Fixes: tag in the upstream
  Linux kernel:

    f7b94bdc1ec1 Bluetooth: af_bluetooth: Fix deadlock (Luiz Augusto von Dentz)

This is an automated message from the kernel commit checker workflow.

[shreeya-patel98]

All fixes are already present.

[bmastbergen]

f7b94bdc1ec1 Bluetooth: af_bluetooth: Fix deadlock (Luiz Augusto von Dentz) is associated with its own CVE:

brett@iconium ~/ciq/vulns % export CVEKERNELTREE=/home/brett/linux ; ./scripts/cve_search f7b94bdc1ec107c92262716b073b3e816d4784fb
CVE-2024-26886 is assigned to git id f7b94bdc1ec107c92262716b073b3e816d4784fb
brett@iconium ~/ciq/vulns %

We marked it with its own VULN and CVE in lts-9.2 so we should probably do the same here:
9bea07d

[shreeya-patel98]

Changes done as requested by Brett.

[github-actions]

🔍 Upstream Linux Kernel Commit Check

• ⚠️ PR commit 2e2e23cc2ed6 (RDMA/core: Refactor rdma_bind_addr) references upstream commit
  8d037973d48c which has been referenced by a Fixes: tag in the upstream
  Linux kernel:

    0e15863015d9 RDMA/core: Update CMA destination address on rdma_resolve_addr (Shiraz Saleem)

• ⚠️ PR commit dd036d0ce001 (vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF) references upstream commit
  226fae124b2d which has been referenced by a Fixes: tag in the upstream
  Linux kernel:

    ae3419fbac84 vc_screen: don't clobber return value in vcs_read (Thomas Weißschuh)
    46d733d0efc7 vc_screen: modify vcs_size() handling in vcs_read() (George Kennedy)

• ⚠️ PR commit 776f12860485 (Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg) references upstream commit
  2e07e8348ea4 which has been referenced by a Fixes: tag in the upstream
  Linux kernel:

    f7b94bdc1ec1 Bluetooth: af_bluetooth: Fix deadlock (Luiz Augusto von Dentz)

This is an automated message from the kernel commit checker workflow.

[bmastbergen]

🥌

[PlaidCat]