In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: Fix a NULL pointer dereference in pnfs_mark_matching_lsegs_return()\n\nCommit de144ff4234f changes _pnfs_return_layout() to call\npnfs_mark_matching_lsegs_return() passing NULL as the struct\npnfs_layout_range argument. Unfortunately,\npnfs_mark_matching_lsegs_return() doesn't check if we have a value here\nbefore dereferencing it, causing an oops.\n\nI'm able to hit this crash consistently when running connectathon basic\ntests on NFS v4.1/v4.2 against Ontap.

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc/uss720: fix memory leak in uss720_probe\n\nuss720_probe forgets to decrease the refcount of usbdev in uss720_probe.\nFix this by decreasing the refcount of usbdev by usb_put_dev.\n\nBUG: memory leak\nunreferenced object 0xffff888101113800 (size 2048):\n comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s)\n hex dump (first 32 bytes):\n ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1...........\n 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 ................\n backtrace:\n [] kmalloc include/linux/slab.h:554 [inline]\n [] kzalloc include/linux/slab.h:684 [inline]\n [] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582\n [] hub_port_connect drivers/usb/core/hub.c:5129 [inline]\n [] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]\n [] port_event drivers/usb/core/hub.c:5509 [inline]\n [] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591\n [] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275\n [] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421\n [] kthread+0x178/0x1b0 kernel/kthread.c:292\n [] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

In the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce()\n\nThe value of mirror->pg_bytes_written should only be updated after a\nsuccessful attempt to flush out the requests on the list.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix null deref accessing lag dev\n\nIt could be the lag dev is null so stop processing the event.\nIn bond_enslave() the active/backup slave being set before setting the\nupper dev so first event is without an upper dev.\nAfter setting the upper dev with bond_master_upper_dev_link() there is\na second event and in that event we have an upper dev.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix a use-after-free\n\nlooks like we forget to set ttm->sg to NULL.\nHit panic below\n\n[ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI\n[ 1235.989074] Call Trace:\n[ 1235.991751] sg_free_table+0x17/0x20\n[ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu]\n[ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu]\n[ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm]\n[ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm]\n[ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm]\n[ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm]\n[ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu]\n[ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu]\n[ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu]\n[ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu]

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions\n\nReported by syzbot:\nHEAD commit: 90c911ad Merge tag 'fixes' of git://git.kernel.org/pub/scm..\ngit tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master\ndashboard link: https://syzkaller.appspot.com/bug?extid=123aa35098fd3c000eb7\ncompiler: Debian clang version 11.0.1-2\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline]\nBUG: KASAN: slab-out-of-bounds in fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732\nRead of size 8 at addr ffff8880145c78f8 by task syz-executor.4/17760\n\nCPU: 0 PID: 17760 Comm: syz-executor.4 Not tainted 5.12.0-rc8-syzkaller #0\nCall Trace:\n \n __dump_stack lib/dump_stack.c:79 [inline]\n dump_stack+0x202/0x31e lib/dump_stack.c:120\n print_address_description+0x5f/0x3b0 mm/kasan/report.c:232\n __kasan_report mm/kasan/report.c:399 [inline]\n kasan_report+0x15c/0x200 mm/kasan/report.c:416\n fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline]\n fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732\n fib6_nh_release+0x9a/0x430 net/ipv6/route.c:3536\n fib6_info_destroy_rcu+0xcb/0x1c0 net/ipv6/ip6_fib.c:174\n rcu_do_batch kernel/rcu/tree.c:2559 [inline]\n rcu_core+0x8f6/0x1450 kernel/rcu/tree.c:2794\n __do_softirq+0x372/0x7a6 kernel/softirq.c:345\n invoke_softirq kernel/softirq.c:221 [inline]\n __irq_exit_rcu+0x22c/0x260 kernel/softirq.c:422\n irq_exit_rcu+0x5/0x20 kernel/softirq.c:434\n sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1100\n \n asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632\nRIP: 0010:lock_acquire+0x1f6/0x720 kernel/locking/lockdep.c:5515\nCode: f6 84 24 a1 00 00 00 02 0f 85 8d 02 00 00 f7 c3 00 02 00 00 49 bd 00 00 00 00 00 fc ff df 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 3d 00 00 00 00 00 4b c7 44 3d 09 00 00 00 00 43 c7 44 3d\nRSP: 0018:ffffc90009e06560 EFLAGS: 00000206\nRAX: 1ffff920013c0cc0 RBX: 0000000000000246 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc90009e066e0 R08: dffffc0000000000 R09: fffffbfff1f992b1\nR10: fffffbfff1f992b1 R11: 0000000000000000 R12: 0000000000000000\nR13: dffffc0000000000 R14: 0000000000000000 R15: 1ffff920013c0cb4\n rcu_lock_acquire+0x2a/0x30 include/linux/rcupdate.h:267\n rcu_read_lock include/linux/rcupdate.h:656 [inline]\n ext4_get_group_info+0xea/0x340 fs/ext4/ext4.h:3231\n ext4_mb_prefetch+0x123/0x5d0 fs/ext4/mballoc.c:2212\n ext4_mb_regular_allocator+0x8a5/0x28f0 fs/ext4/mballoc.c:2379\n ext4_mb_new_blocks+0xc6e/0x24f0 fs/ext4/mballoc.c:4982\n ext4_ext_map_blocks+0x2be3/0x7210 fs/ext4/extents.c:4238\n ext4_map_blocks+0xab3/0x1cb0 fs/ext4/inode.c:638\n ext4_getblk+0x187/0x6c0 fs/ext4/inode.c:848\n ext4_bread+0x2a/0x1c0 fs/ext4/inode.c:900\n ext4_append+0x1a4/0x360 fs/ext4/namei.c:67\n ext4_init_new_dir+0x337/0xa10 fs/ext4/namei.c:2768\n ext4_mkdir+0x4b8/0xc00 fs/ext4/namei.c:2814\n vfs_mkdir+0x45b/0x640 fs/namei.c:3819\n ovl_do_mkdir fs/overlayfs/overlayfs.h:161 [inline]\n ovl_mkdir_real+0x53/0x1a0 fs/overlayfs/dir.c:146\n ovl_create_real+0x280/0x490 fs/overlayfs/dir.c:193\n ovl_workdir_create+0x425/0x600 fs/overlayfs/super.c:788\n ovl_make_workdir+0xed/0x1140 fs/overlayfs/super.c:1355\n ovl_get_workdir fs/overlayfs/super.c:1492 [inline]\n ovl_fill_super+0x39ee/0x5370 fs/overlayfs/super.c:2035\n mount_nodev+0x52/0xe0 fs/super.c:1413\n legacy_get_tree+0xea/0x180 fs/fs_context.c:592\n vfs_get_tree+0x86/0x270 fs/super.c:1497\n do_new_mount fs/namespace.c:2903 [inline]\n path_mount+0x196f/0x2be0 fs/namespace.c:3233\n do_mount fs/namespace.c:3246 [inline]\n __do_sys_mount fs/namespace.c:3454 [inline]\n __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3431\n do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x4665f9\nCode: ff ff c3 66 2e 0f 1f 84 \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: fix refcount leak in htb_parent_to_leaf_offload\n\nThe commit ae81feb7338c ("sch_htb: fix null pointer dereference\non a null new_q") fixes a NULL pointer dereference bug, but it\nis not correct.\n\nBecause htb_graft_helper properly handles the case when new_q\nis NULL, and after the previous patch by skipping this call\nwhich creates an inconsistency : dev_queue->qdisc will still\npoint to the old qdisc, but cl->parent->leaf.q will point to\nthe new one (which will be noop_qdisc, because new_q was NULL).\nThe code is based on an assumption that these two pointers are\nthe same, so it can lead to refcount leaks.\n\nThe correct fix is to add a NULL pointer check to protect\nqdisc_refcount_inc inside htb_parent_to_leaf_offload.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: abort in rename_exchange if we fail to insert the second ref\n\nError injection stress uncovered a problem where we'd leave a dangling\ninode ref if we failed during a rename_exchange. This happens because\nwe insert the inode ref for one side of the rename, and then for the\nother side. If this second inode ref insert fails we'll leave the first\none dangling and leave a corrupt file system behind. Fix this by\naborting if we did the insert for the first inode ref.

In the Linux kernel, the following vulnerability has been resolved:\n\nipmi: ssif: initialize ssif_info->client early\n\nDuring probe ssif_info->client is dereferenced in error path. However,\nit is set when some of the error checking has already been done. This\ncauses following kernel crash if an error path is taken:\n\n[ 30.645593][ T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present\n[ 30.657616][ T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088\n...\n[ 30.657723][ T674] pc : __dev_printk+0x28/0xa0\n[ 30.657732][ T674] lr : _dev_err+0x7c/0xa0\n...\n[ 30.657772][ T674] Call trace:\n[ 30.657775][ T674] __dev_printk+0x28/0xa0\n[ 30.657778][ T674] _dev_err+0x7c/0xa0\n[ 30.657781][ T674] ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e]\n[ 30.657791][ T674] i2c_device_probe+0x37c/0x3c0\n...\n\nInitialize ssif_info->client before any error path can be taken. Clear\ni2c_client data in the error path to prevent the dangling pointer from\nleaking.

In the Linux kernel, the following vulnerability has been resolved:\n\nuio_hv_generic: Fix another memory leak in error handling paths\n\nMemory allocated by 'vmbus_alloc_ring()' at the beginning of the probe\nfunction is never freed in the error handling path.\n\nAdd the missing 'vmbus_free_ring()' call.\n\nNote that it is already freed in the .remove function.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/nfc: fix use-after-free llcp_sock_bind/connect\n\nCommits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()")\nand c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()")\nfixed a refcount leak bug in bind/connect but introduced a\nuse-after-free if the same local is assigned to 2 different sockets.\n\nThis can be triggered by the following simple program:\n int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP );\n int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP );\n memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) );\n addr.sa_family = AF_NFC;\n addr.nfc_protocol = NFC_PROTO_NFC_DEP;\n bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) )\n bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) )\n close(sock1);\n close(sock2);\n\nFix this by assigning NULL to llcp_sock->local after calling\nnfc_llcp_local_put.\n\nThis addresses CVE-2021-23134.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Stop looking for coalesced MMIO zones if the bus is destroyed\n\nAbort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev()\nfails to allocate memory for the new instance of the bus. If it can't\ninstantiate a new bus, unregister_dev() destroys all devices _except_ the\ntarget device. But, it doesn't tell the caller that it obliterated the\nbus and invoked the destructor for all devices that were on the bus. In\nthe coalesced MMIO case, this can result in a deleted list entry\ndereference due to attempting to continue iterating on coalesced_zones\nafter future entries (in the walk) have been deleted.\n\nOpportunistically add curly braces to the for-loop, which encompasses\nmany lines but sneaks by without braces due to the guts being a single\nif statement.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails\n\nThe spi controller supports 44-bit address space on AXI in DMA mode,\nso set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.\nIn addition, if dma_map_single fails, it should return immediately\ninstead of continuing doing the DMA operation which bases on invalid\naddress.\n\nThis fixes the following crash which occurs in reading a big block\nfrom flash:\n\n[ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots)\n[ 123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped\n[ 123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0\n[ 123.792536] Mem abort info:\n[ 123.795313] ESR = 0x96000145\n[ 123.798351] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 123.803655] SET = 0, FnV = 0\n[ 123.806693] EA = 0, S1PTW = 0\n[ 123.809818] Data abort info:\n[ 123.812683] ISV = 0, ISS = 0x00000145\n[ 123.816503] CM = 1, WnR = 1\n[ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000\n[ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000\n[ 123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix off by one in hdmi_14_process_transaction()\n\nThe hdcp_i2c_offsets[] array did not have an entry for\nHDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one\nread overflow. I added an entry and copied the 0x0 value for the offset\nfrom similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c.\n\nI also declared several of these arrays as having HDCP_MESSAGE_ID_MAX\nentries. This doesn't change the code, but it's just a belt and\nsuspenders approach to try future proof the code.

In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7615: fix tx skb dma unmap\n\nThe first pointer in the txp needs to be unmapped as well, otherwise it will\nleak DMA mapping entries

In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7915: fix tx skb dma unmap\n\nThe first pointer in the txp needs to be unmapped as well, otherwise it will\nleak DMA mapping entries

In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7921: fix memory leak in mt7921_coredump_work\n\nFix possible memory leak in mt7921_coredump_work.

In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7615: fix memory leak in mt7615_coredump_work\n\nSimilar to the issue fixed in mt7921_coredump_work, fix a possible memory\nleak in mt7615_coredump_work routine.

In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: connac: fix kernel warning adding monitor interface\n\nFix the following kernel warning adding a monitor interface in\nmt76_connac_mcu_uni_add_dev routine.\n\n[ 507.984882] ------------[ cut here ]------------\n[ 507.989515] WARNING: CPU: 1 PID: 3017 at mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]\n[ 508.059379] CPU: 1 PID: 3017 Comm: ifconfig Not tainted 5.4.98 #0\n[ 508.065461] Hardware name: MT7622_MT7531 RFB (DT)\n[ 508.070156] pstate: 80000005 (Nzcv daif -PAN -UAO)\n[ 508.074939] pc : mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]\n[ 508.081806] lr : mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]\n[ 508.087367] sp : ffffffc013a33930\n[ 508.090671] x29: ffffffc013a33930 x28: ffffff801e628ac0\n[ 508.095973] x27: ffffff801c7f1200 x26: ffffff801c7eb008\n[ 508.101275] x25: ffffff801c7eaef0 x24: ffffff801d025610\n[ 508.106577] x23: ffffff801d022990 x22: ffffff801d024de8\n[ 508.111879] x21: ffffff801d0226a0 x20: ffffff801c7eaee8\n[ 508.117181] x19: ffffff801d0226a0 x18: 000000005d00b000\n[ 508.122482] x17: 00000000ffffffff x16: 0000000000000000\n[ 508.127785] x15: 0000000000000080 x14: ffffff801d704000\n[ 508.133087] x13: 0000000000000040 x12: 0000000000000002\n[ 508.138389] x11: 000000000000000c x10: 0000000000000000\n[ 508.143691] x9 : 0000000000000020 x8 : 0000000000000001\n[ 508.148992] x7 : 0000000000000000 x6 : 0000000000000000\n[ 508.154294] x5 : ffffff801c7eaee8 x4 : 0000000000000006\n[ 508.159596] x3 : 0000000000000001 x2 : 0000000000000000\n[ 508.164898] x1 : ffffff801c7eac08 x0 : ffffff801d0226a0\n[ 508.170200] Call trace:\n[ 508.172640] mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]\n[ 508.179159] mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]\n[ 508.184394] drv_add_interface+0x34/0x88 [mac80211]\n[ 508.189271] ieee80211_add_virtual_monitor+0xe0/0xb48 [mac80211]\n[ 508.195277] ieee80211_do_open+0x86c/0x918 [mac80211]\n[ 508.200328] ieee80211_do_open+0x900/0x918 [mac80211]\n[ 508.205372] __dev_open+0xcc/0x150\n[ 508.208763] __dev_change_flags+0x134/0x198\n[ 508.212937] dev_change_flags+0x20/0x60\n[ 508.216764] devinet_ioctl+0x3e8/0x748\n[ 508.220503] inet_ioctl+0x1e4/0x350\n[ 508.223983] sock_do_ioctl+0x48/0x2a0\n[ 508.227635] sock_ioctl+0x310/0x4f8\n[ 508.231116] do_vfs_ioctl+0xa4/0xac0\n[ 508.234681] ksys_ioctl+0x44/0x90\n[ 508.237985] __arm64_sys_ioctl+0x1c/0x48\n[ 508.241901] el0_svc_common.constprop.1+0x7c/0x100\n[ 508.246681] el0_svc_handler+0x18/0x20\n[ 508.250421] el0_svc+0x8/0x1c8\n[ 508.253465] ---[ end trace c7b90fee13d72c39 ]---\n[ 508.261278] ------------[ cut here ]------------

In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7915: fix txrate reporting\n\nProperly check rate_info to fix unexpected reporting.\n\n[ 1215.161863] Call trace:\n[ 1215.164307] cfg80211_calculate_bitrate+0x124/0x200 [cfg80211]\n[ 1215.170139] ieee80211s_update_metric+0x80/0xc0 [mac80211]\n[ 1215.175624] ieee80211_tx_status_ext+0x508/0x838 [mac80211]\n[ 1215.181190] mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e]\n[ 1215.186580] mt7915_mac_tx_free+0x324/0x7c0 [mt7915e]\n[ 1215.191623] mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e]\n[ 1215.196582] mt76_dma_cleanup+0x7b0/0x11d0 [mt76]\n[ 1215.201276] __napi_poll+0x38/0xf8\n[ 1215.204668] napi_workfn+0x40/0x80\n[ 1215.208062] process_one_work+0x1fc/0x390\n[ 1215.212062] worker_thread+0x48/0x4d0\n[ 1215.215715] kthread+0x120/0x128\n[ 1215.218935] ret_from_fork+0x10/0x1c

In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix inode leak on getattr error in __fh_to_dentry

In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: do asoc update earlier in sctp_sf_do_dupcook_a\n\nThere's a panic that occurs in a few of envs, the call trace is as below:\n\n [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI\n [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp]\n [] sctp_assoc_control_transport+0x1b9/0x210 [sctp]\n [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp]\n [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp]\n [] sctp_do_sm+0xc3/0x2a0 [sctp]\n [] sctp_generate_timeout_event+0x81/0xf0 [sctp]\n\nThis is caused by a transport use-after-free issue. When processing a\nduplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK\nand SHUTDOWN chunks are allocated with the transort from the new asoc.\nHowever, later in the sideeffect machine, the old asoc is used to send\nthem out and old asoc's shutdown_last_sent_to is set to the transport\nthat SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually\nbelongs to the new asoc. After the new_asoc is freed and the old asoc\nT2 timeout, the old asoc's shutdown_last_sent_to that is already freed\nwould be accessed in sctp_sf_t2_timer_expire().\n\nThanks Alexander and Jere for helping dig into this issue.\n\nTo fix it, this patch is to do the asoc update first, then allocate\nthe COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This\nwould make more sense, as a chunk from an asoc shouldn't be sent out\nwith another asoc. We had fixed quite a few issues caused by this.

In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: scan: Fix a memory leak in an error handling path\n\nIf 'acpi_device_set_name()' fails, we must free\n'acpi_device_bus_id->bus_id' or there is a (potential) memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: uniphier-sd: Fix a resource leak in the remove function\n\nA 'tmio_mmc_host_free()' call is missing in the remove function, in order\nto balance a 'tmio_mmc_host_alloc()' call in the probe.\nThis is done in the error handling path of the probe, but not in the remove\nfunction.\n\nAdd the missing call.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race between transaction aborts and fsyncs leading to use-after-free\n\nThere is a race between a task aborting a transaction during a commit,\na task doing an fsync and the transaction kthread, which leads to an\nuse-after-free of the log root tree. When this happens, it results in a\nstack trace like the following:\n\n BTRFS info (device dm-0): forced readonly\n BTRFS warning (device dm-0): Skipping commit of aborted transaction.\n BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure\n BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5)\n BTRFS warning (device dm-0): Skipping commit of aborted transaction.\n BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10\n BTRFS error (device dm-0): error writing primary super block to device 1\n BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10\n BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10\n BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10\n BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers)\n BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure\n general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI\n CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__mutex_lock+0x139/0xa40\n Code: c0 74 19 (...)\n RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202\n RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002\n RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040\n R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358\n FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n ? __btrfs_handle_fs_error+0xde/0x146 [btrfs]\n ? btrfs_sync_log+0x7c1/0xf20 [btrfs]\n ? btrfs_sync_log+0x7c1/0xf20 [btrfs]\n btrfs_sync_log+0x7c1/0xf20 [btrfs]\n btrfs_sync_file+0x40c/0x580 [btrfs]\n do_fsync+0x38/0x70\n __x64_sys_fsync+0x10/0x20\n do_syscall_64+0x33/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7fa9142a55c3\n Code: 8b 15 09 (...)\n RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a\n RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3\n RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005\n RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340\n R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0\n Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...)\n ---[ end trace ee2f1b19327d791d ]---\n\nThe steps that lead to this crash are the following:\n\n1) We are at transaction N;\n\n2) We have two tasks with a transaction handle attached to transaction N.\n Task A and Task B. Task B is doing an fsync;\n\n3) Task B is at btrfs_sync_log(), and has saved fs_info->log_root_tree\n into a local variable named 'log_root_tree' at the top of\n btrfs_sync_log(). Task B is about to call write_all_supers(), but\n before that...\n\n4) Task A calls btrfs_commit_transaction(), and after it sets the\n transaction state to TRANS_STATE_COMMIT_START, an error happens before\n it w\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtiofs: fix memory leak in virtio_fs_probe()\n\nWhen accidentally passing twice the same tag to qemu, kmemleak ended up\nreporting a memory leak in virtiofs. Also, looking at the log I saw the\nfollowing error (that's when I realised the duplicated tag):\n\n virtiofs: probe of virtio5 failed with error -17\n\nHere's the kmemleak log for reference:\n\nunreferenced object 0xffff888103d47800 (size 1024):\n comm "systemd-udevd", pid 118, jiffies 4294893780 (age 18.340s)\n hex dump (first 32 bytes):\n 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........\n ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff ................\n backtrace:\n [<000000000ebb87c1>] virtio_fs_probe+0x171/0x7ae [virtiofs]\n [<00000000f8aca419>] virtio_dev_probe+0x15f/0x210\n [<000000004d6baf3c>] really_probe+0xea/0x430\n [<00000000a6ceeac8>] device_driver_attach+0xa8/0xb0\n [<00000000196f47a7>] __driver_attach+0x98/0x140\n [<000000000b20601d>] bus_for_each_dev+0x7b/0xc0\n [<00000000399c7b7f>] bus_add_driver+0x11b/0x1f0\n [<0000000032b09ba7>] driver_register+0x8f/0xe0\n [<00000000cdd55998>] 0xffffffffa002c013\n [<000000000ea196a2>] do_one_initcall+0x64/0x2e0\n [<0000000008f727ce>] do_init_module+0x5c/0x260\n [<000000003cdedab6>] __do_sys_finit_module+0xb5/0x120\n [<00000000ad2f48c6>] do_syscall_64+0x33/0x40\n [<00000000809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: fix stack OOB read while fragmenting IPv4 packets\n\nrunning openvswitch on kernels built with KASAN, it's possible to see the\nfollowing splat while testing fragmentation of IPv4 packets:\n\n BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60\n Read of size 1 at addr ffff888112fc713c by task handler2/1367\n\n CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418\n Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014\n Call Trace:\n dump_stack+0x92/0xc1\n print_address_description.constprop.7+0x1a/0x150\n kasan_report.cold.13+0x7f/0x111\n ip_do_fragment+0x1b03/0x1f60\n ovs_fragment+0x5bf/0x840 [openvswitch]\n do_execute_actions+0x1bd5/0x2400 [openvswitch]\n ovs_execute_actions+0xc8/0x3d0 [openvswitch]\n ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch]\n genl_family_rcv_msg_doit.isra.15+0x227/0x2d0\n genl_rcv_msg+0x287/0x490\n netlink_rcv_skb+0x120/0x380\n genl_rcv+0x24/0x40\n netlink_unicast+0x439/0x630\n netlink_sendmsg+0x719/0xbf0\n sock_sendmsg+0xe2/0x110\n ____sys_sendmsg+0x5ba/0x890\n ___sys_sendmsg+0xe9/0x160\n __sys_sendmsg+0xd3/0x170\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7f957079db07\n Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48\n RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07\n RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019\n RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730\n R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000\n R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0\n\n The buggy address belongs to the page:\n page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7\n flags: 0x17ffffc0000000()\n raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\n\n addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame:\n ovs_fragment+0x0/0x840 [openvswitch]\n\n this frame has 2 objects:\n [32, 144) 'ovs_dst'\n [192, 424) 'ovs_rt'\n\n Memory state around the buggy address:\n ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00\n >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00\n ^\n ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00\n\nfor IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then,\nin the following call graph:\n\n ip_do_fragment()\n ip_skb_dst_mtu()\n ip_dst_mtu_maybe_forward()\n ip_mtu_locked()\n\nthe pointer to struct dst_entry is used as pointer to struct rtable: this\nturns the access to struct members like rt_mtu_locked into an OOB read in\nthe stack. Fix this changing the temporary variable used for IPv4 packets\nin ovs_fragment(), similarly to what is done for IPv6 few lines below.

In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure\n\nWhen failing the driver probe because of invalid firmware properties,\nthe GTDT driver unmaps the interrupt that it mapped earlier.\n\nHowever, it never checks whether the mapping of the interrupt actially\nsucceeded. Even more, should the firmware report an illegal interrupt\nnumber that overlaps with the GIC SGI range, this can result in an\nIPI being unmapped, and subsequent fireworks (as reported by Dann\nFrazier).\n\nRework the driver to have a slightly saner behaviour and actually\ncheck whether the interrupt has been mapped before unmapping things.

In the Linux kernel, the following vulnerability has been resolved:\n\nNFS: fs_context: validate UDP retrans to prevent shift out-of-bounds\n\nFix shift out-of-bounds in xprt_calc_majortimeo(). This is caused\nby a garbage timeout (retrans) mount option being passed to nfs mount,\nin this case from syzkaller.\n\nIf the protocol is XPRT_TRANSPORT_UDP, then 'retrans' is a shift\nvalue for a 64-bit long integer, so 'retrans' cannot be >= 64.\nIf it is >= 64, fail the mount and return an error.

In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: efi: Use local variable for calculating final log size\n\nWhen tpm_read_log_efi is called multiple times, which happens when\none loads and unloads a TPM2 driver multiple times, then the global\nvariable efi_tpm_final_log_size will at some point become a negative\nnumber due to the subtraction of final_events_preboot_size occurring\neach time. Use a local variable to avoid this integer underflow.\n\nThe following issue is now resolved:\n\nMar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\nMar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy]\nMar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20\nMar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4\nMar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206\nMar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f\nMar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d\nMar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073\nMar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5\nMar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018\nMar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000\nMar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nMar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0\nMar 8 15:35:12 hibinst kernel: Call Trace:\nMar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7\nMar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0\nMar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260\nMar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy]\nMar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370\nMar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0\nMar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370

In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1: properly indicate failure when ending a failed write request\n\nThis patch addresses a data corruption bug in raid1 arrays using bitmaps.\nWithout this fix, the bitmap bits for the failed I/O end up being cleared.\n\nSince we are in the failure leg of raid1_end_write_request, the request\neither needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).

In the Linux kernel, the following vulnerability has been resolved:\n\next4: always panic when errors=panic is specified\n\nBefore commit 014c9caa29d3 ("ext4: make ext4_abort() use\n__ext4_error()"), the following series of commands would trigger a\npanic:\n\n1. mount /dev/sda -o ro,errors=panic test\n2. mount /dev/sda -o remount,abort test\n\nAfter commit 014c9caa29d3, remounting a file system using the test\nmount option "abort" will no longer trigger a panic. This commit will\nrestore the behaviour immediately before commit 014c9caa29d3.\n(However, note that the Linux kernel's behavior has not been\nconsistent; some previous kernel versions, including 5.4 and 4.19\nsimilarly did not panic after using the mount option "abort".)\n\nThis also makes a change to long-standing behaviour; namely, the\nfollowing series commands will now cause a panic, when previously it\ndid not:\n\n1. mount /dev/sda -o ro,errors=panic test\n2. echo test > /sys/fs/ext4/sda/trigger_fs_error\n\nHowever, this makes ext4's behaviour much more consistent, so this is\na good thing.

In the Linux kernel, the following vulnerability has been resolved:\n\ndm rq: fix double free of blk_mq_tag_set in dev remove after table load fails\n\nWhen loading a device-mapper table for a request-based mapped device,\nand the allocation/initialization of the blk_mq_tag_set for the device\nfails, a following device remove will cause a double free.\n\nE.g. (dmesg):\n device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device\n device-mapper: ioctl: unable to set up device queue for new table.\n Unable to handle kernel pointer dereference in virtual kernel address space\n Failing address: 0305e098835de000 TEID: 0305e098835de803\n Fault in home space mode while using kernel ASCE.\n AS:000000025efe0007 R3:0000000000000024\n Oops: 0038 ilc:3 [#1] SMP\n Modules linked in: ... lots of modules ...\n Supported: Yes, External\n CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3\n Hardware name: IBM 8561 T01 7I2 (LPAR)\n Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330)\n R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3\n Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000\n 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000\n 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640\n 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8\n Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8\n 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58\n #000000025e368ec4: e3b010000008 ag %r11,0(%r1)\n >000000025e368eca: e310b0080004 lg %r1,8(%r11)\n 000000025e368ed0: a7110001 tmll %r1,1\n 000000025e368ed4: a7740129 brc 7,25e369126\n 000000025e368ed8: e320b0080004 lg %r2,8(%r11)\n 000000025e368ede: b904001b lgr %r1,%r11\n Call Trace:\n [<000000025e368eca>] kfree+0x42/0x330\n [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8\n [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod]\n [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod]\n [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod]\n [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod]\n [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod]\n [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod]\n [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0\n [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40\n [<000000025e8c15ac>] system_call+0xd8/0x2c8\n Last Breaking-Event-Address:\n [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8\n Kernel panic - not syncing: Fatal exception: panic_on_oops\n\nWhen allocation/initialization of the blk_mq_tag_set fails in\ndm_mq_init_request_queue(), it is uninitialized/freed, but the pointer\nis not reset to NULL; so when dev_remove() later gets into\ndm_mq_cleanup_mapped_device() it sees the pointer and tries to\nuninitialize and free it again.\n\nFix this by setting the pointer to NULL in dm_mq_init_request_queue()\nerror-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().

In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix async_free_space accounting for empty parcels\n\nIn 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area shared with user space")\nfixed a kernel structure visibility issue. As part of that patch,\nsizeof(void *) was used as the buffer size for 0-length data payloads so\nthe driver could detect abusive clients sending 0-length asynchronous\ntransactions to a server by enforcing limits on async_free_size.\n\nUnfortunately, on the "free" side, the accounting of async_free_space\ndid not add the sizeof(void *) back. The result was that up to 8-bytes of\nasync_free_space were leaked on every async transaction of 8-bytes or\nless. These small transactions are uncommon, so this accounting issue\nhas gone undetected for several years.\n\nThe fix is to use "buffer_size" (the allocated buffer size) instead of\n"size" (the logical buffer size) when updating the async_free_space\nduring the free operation. These are the same except for this\ncorner case of asynchronous transactions with payloads < 8 bytes.

In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Clear stale IIR value on instruction access rights trap\n\nWhen a trap 7 (Instruction access rights) occurs, this means the CPU\ncouldn't execute an instruction due to missing execute permissions on\nthe memory region. In this case it seems the CPU didn't even fetched\nthe instruction from memory and thus did not store it in the cr19 (IIR)\nregister before calling the trap handler. So, the trap handler will find\nsome random old stale value in cr19.\n\nThis patch simply overwrites the stale IIR value with a constant magic\n"bad food" value (0xbaadf00d), in the hope people don't start to try to\nunderstand the various random IIR values in trap 7 dumps.

Memory safety bug present in Firefox ESR 128.10, and Thunderbird 128.10. This bug showed evidence of memory corruption and we presume that with enough effort this could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR < 128.11.

Memory safety bugs present in Firefox 138, Thunderbird 138, Firefox ESR 128.10, and Thunderbird 128.10. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 139 and Firefox ESR < 128.11.

A clickjacking vulnerability could have been used to trick a user into leaking saved payment card details to a malicious page. This vulnerability affects Firefox < 139 and Firefox ESR < 128.11.

Script elements loading cross-origin resources generated load and error events which leaked information enabling XS-Leaks attacks. This vulnerability affects Firefox < 139 and Firefox ESR < 128.11.

No description is available for this CVE.

A vulnerability was found in GNU Binutils up to version 2.44 and affects the elf_gc_sweep function of the bfd/elflink.c file of the component ld. The manipulation leads to memory corruption and a program crash. An attacker must have local access to exploit this vulnerability. Upgrading to version 2.45 is advised to address this issue.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_frag: fix stack OOB read while fragmenting IPv4 packets\n\nwhen 'act_mirred' tries to fragment IPv4 packets that had been previously\nre-assembled using 'act_ct', splats like the following can be observed on\nkernels built with KASAN:\n\n BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60\n Read of size 1 at addr ffff888147009574 by task ping/947\n\n CPU: 0 PID: 947 Comm: ping Not tainted 5.12.0-rc6+ #418\n Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014\n Call Trace:\n \n dump_stack+0x92/0xc1\n print_address_description.constprop.7+0x1a/0x150\n kasan_report.cold.13+0x7f/0x111\n ip_do_fragment+0x1b03/0x1f60\n sch_fragment+0x4bf/0xe40\n tcf_mirred_act+0xc3d/0x11a0 [act_mirred]\n tcf_action_exec+0x104/0x3e0\n fl_classify+0x49a/0x5e0 [cls_flower]\n tcf_classify_ingress+0x18a/0x820\n __netif_receive_skb_core+0xae7/0x3340\n __netif_receive_skb_one_core+0xb6/0x1b0\n process_backlog+0x1ef/0x6c0\n __napi_poll+0xaa/0x500\n net_rx_action+0x702/0xac0\n __do_softirq+0x1e4/0x97f\n do_softirq+0x71/0x90\n \n __local_bh_enable_ip+0xdb/0xf0\n ip_finish_output2+0x760/0x2120\n ip_do_fragment+0x15a5/0x1f60\n __ip_finish_output+0x4c2/0xea0\n ip_output+0x1ca/0x4d0\n ip_send_skb+0x37/0xa0\n raw_sendmsg+0x1c4b/0x2d00\n sock_sendmsg+0xdb/0x110\n __sys_sendto+0x1d7/0x2b0\n __x64_sys_sendto+0xdd/0x1b0\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7f82e13853eb\n Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89\n RSP: 002b:00007ffe01fad888 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\n RAX: ffffffffffffffda RBX: 00005571aac13700 RCX: 00007f82e13853eb\n RDX: 0000000000002330 RSI: 00005571aac13700 RDI: 0000000000000003\n RBP: 0000000000002330 R08: 00005571aac10500 R09: 0000000000000010\n R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe01faefb0\n R13: 00007ffe01fad890 R14: 00007ffe01fad980 R15: 00005571aac0f0a0\n\n The buggy address belongs to the page:\n page:000000001dff2e03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x147009\n flags: 0x17ffffc0001000(reserved)\n raw: 0017ffffc0001000 ffffea00051c0248 ffffea00051c0248 0000000000000000\n raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888147009400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff888147009480: f1 f1 f1 f1 04 f2 f2 f2 f2 f2 f2 f2 00 00 00 00\n >ffff888147009500: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2\n ^\n ffff888147009580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff888147009600: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2\n\nfor IPv4 packets, sch_fragment() uses a temporary struct dst_entry. Then,\nin the following call graph:\n\n ip_do_fragment()\n ip_skb_dst_mtu()\n ip_dst_mtu_maybe_forward()\n ip_mtu_locked()\n\nthe pointer to struct dst_entry is used as pointer to struct rtable: this\nturns the access to struct members like rt_mtu_locked into an OOB read in\nthe stack. Fix this changing the temporary variable used for IPv4 packets\nin sch_fragment(), similarly to what is done for IPv6 few lines below.

Due to insufficient escaping of the ampersand character in the “Copy as cURL” feature, an attacker could trick a user into using this command, potentially leading to local code execution on the user's system.\n*This bug only affects Firefox for Windows. Other versions of Firefox are unaffected.* This vulnerability affects Firefox < 139, Firefox ESR < 115.24, and Firefox ESR < 128.11.

Previewing a response in Devtools ignored CSP headers, which could have allowed content injection attacks. This vulnerability affects Firefox < 139.

In certain cases, SNI could have been sent unencrypted even when encrypted DNS was enabled. This vulnerability affects Firefox < 139.

Due to insufficient escaping of the newline character in the “Copy as cURL” feature, an attacker could trick a user into using this command, potentially leading to local code execution on the user's system. This vulnerability affects Firefox < 139, Firefox ESR < 115.24, and Firefox ESR < 128.11.

Error handling for script execution was incorrectly isolated from web content, which could have allowed cross-origin leak attacks. This vulnerability affects Firefox < 139, Firefox ESR < 115.24, and Firefox ESR < 128.11.

A double-free could have occurred in `vpx_codec_enc_init_multi` after a failed allocation when initializing the encoder for WebRTC. This could have caused memory corruption and a potentially exploitable crash. This vulnerability affects Firefox < 139, Firefox ESR < 115.24, and Firefox ESR < 128.11.

In the Linux kernel, the following vulnerability has been resolved:\nHID: pidff: Make sure to fetch pool before checking SIMULTANEOUS_MAX\nAs noted by Anssi some 20 years ago, pool report is sometimes messed up.\nThis worked fine on many devices but casued oops on VRS DirectForce PRO.\nHere, we're making sure pool report is refetched before trying to access\nany of it's fields. While loop was replaced with a for loop + exit\nconditions were moved aroud to decrease the possibility of creating an\ninfinite loop scenario.

FreeType 2.8.1 has a signed integer overflow in cf2_doFlex in cff/cf2intrp.c..

A vulnerability, which was classified as critical, was found in GNU Binutils 2.43. Affected is the function bfd_elf_reloc_symbol_deleted_p of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The patch is identified as b425859021d17adf62f06fb904797cf8642986ad. It is recommended to apply a patch to fix this issue.

A vulnerability classified as critical was found in GNU Binutils 2.43. This vulnerability affects the function _bfd_elf_gc_mark_rsec of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 931494c9a89558acb36a03a340c01726545eef24. It is recommended to apply a patch to fix this issue.

A vulnerability classified as problematic has been found in GNU Binutils 2.43. This affects the function _bfd_elf_write_section_eh_frame of the file bfd/elf-eh-frame.c of the component ld. The manipulation leads to memory corruption. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

A vulnerability was found in GNU Binutils 2.43. It has been rated as critical. Affected by this issue is the function bfd_putl64 of the file bfd/libbfd.c of the component ld. The manipulation leads to memory corruption. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. It is recommended to upgrade the affected component. The code maintainer explains, that "[t]his bug has been fixed at some point between the 2.43 and 2.44 releases".

A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. Affected by this vulnerability is the function bfd_putl64 of the file libbfd.c of the component ld. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 75086e9de1707281172cc77f178e7949a4414ed0. It is recommended to apply a patch to fix this issue.

A vulnerability was found in GNU Binutils 2.43 and classified as critical. This issue affects the function _bfd_elf_gc_mark_rsec of the file elflink.c of the component ld. The manipulation leads to heap-based buffer overflow. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The patch is named f9978defb6fab0bd8583942d97c112b0932ac814. It is recommended to apply a patch to fix this issue.

A vulnerability classified as problematic was found in GNU Binutils 2.43/2.44. Affected by this vulnerability is the function bfd_set_format of the file format.c. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 2.45 is able to address this issue. The identifier of the patch is 8d97c1a53f3dc9fd8e1ccdb039b8a33d50133150. It is recommended to upgrade the affected component.

A vulnerability classified as problematic has been found in GNU Binutils 2.43. Affected is the function xstrdup of the file xstrdup.c of the component ld. The manipulation leads to memory leak. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. This vulnerability affects the function bfd_malloc of the file libbfd.c of the component ld. The manipulation leads to memory leak. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

There exists a heap buffer overflow vulnerable in Abseil-cpp. The sized constructors, reserve(), and rehash() methods of absl::{flat,node}hash{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container's backing store, and a subsequent out-of-bounds memory write. Subsequent accesses to the container might also access out-of-bounds memory. We recommend upgrading past commit 5a0e2cb5e3958dd90bb8569a2766622cb74d90c1

A vulnerability was found in FFmpeg up to 7.0.1. It has been classified as critical. This affects the function pnm_decode_frame in the library /libavcodec/pnmdec.c. The manipulation leads to heap-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 7.0.2 is able to address this issue. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-273651.

https://www.gnu.org/software/binutils/ nm >=2.43 is affected by: Incorrect Access Control. The type of exploitation is: local. The component is: `nm --without-symbol-version` function.

A flaw was found in FFmpeg's DASH playlist support. This vulnerability allows arbitrary HTTP GET requests to be made on behalf of the machine running FFmpeg via a crafted DASH playlist containing malicious URLs.

A flaw was found in FFmpeg. This vulnerability allows unexpected additional CPU load and storage consumption, potentially leading to degraded performance or denial of service via the demuxing of arbitrary data as XBIN-formatted data without proper format validation.

In the Linux kernel, the following vulnerability has been resolved:\n\narm64: dts: qcom: sc7280: Mark PCIe controller as cache coherent\n\nIf the controller is not marked as cache coherent, then kernel will\ntry to ensure coherency during dma-ops and that may cause data corruption.\nSo, mark the PCIe node as dma-coherent as the devices on PCIe bus are\ncache coherent.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a race condition between btf_put() and map_free()\n\nWhen running `./test_progs -j` in my local vm with latest kernel,\nI once hit a kasan error like below:\n\n [ 1887.184724] BUG: KASAN: slab-use-after-free in bpf_rb_root_free+0x1f8/0x2b0\n [ 1887.185599] Read of size 4 at addr ffff888106806910 by task kworker/u12:2/2830\n [ 1887.186498]\n [ 1887.186712] CPU: 3 PID: 2830 Comm: kworker/u12:2 Tainted: G OEL 6.7.0-rc3-00699-g90679706d486-dirty #494\n [ 1887.188034] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n [ 1887.189618] Workqueue: events_unbound bpf_map_free_deferred\n [ 1887.190341] Call Trace:\n [ 1887.190666] \n [ 1887.190949] dump_stack_lvl+0xac/0xe0\n [ 1887.191423] ? nf_tcp_handle_invalid+0x1b0/0x1b0\n [ 1887.192019] ? panic+0x3c0/0x3c0\n [ 1887.192449] print_report+0x14f/0x720\n [ 1887.192930] ? preempt_count_sub+0x1c/0xd0\n [ 1887.193459] ? __virt_addr_valid+0xac/0x120\n [ 1887.194004] ? bpf_rb_root_free+0x1f8/0x2b0\n [ 1887.194572] kasan_report+0xc3/0x100\n [ 1887.195085] ? bpf_rb_root_free+0x1f8/0x2b0\n [ 1887.195668] bpf_rb_root_free+0x1f8/0x2b0\n [ 1887.196183] ? __bpf_obj_drop_impl+0xb0/0xb0\n [ 1887.196736] ? preempt_count_sub+0x1c/0xd0\n [ 1887.197270] ? preempt_count_sub+0x1c/0xd0\n [ 1887.197802] ? _raw_spin_unlock+0x1f/0x40\n [ 1887.198319] bpf_obj_free_fields+0x1d4/0x260\n [ 1887.198883] array_map_free+0x1a3/0x260\n [ 1887.199380] bpf_map_free_deferred+0x7b/0xe0\n [ 1887.199943] process_scheduled_works+0x3a2/0x6c0\n [ 1887.200549] worker_thread+0x633/0x890\n [ 1887.201047] ? __kthread_parkme+0xd7/0xf0\n [ 1887.201574] ? kthread+0x102/0x1d0\n [ 1887.202020] kthread+0x1ab/0x1d0\n [ 1887.202447] ? pr_cont_work+0x270/0x270\n [ 1887.202954] ? kthread_blkcg+0x50/0x50\n [ 1887.203444] ret_from_fork+0x34/0x50\n [ 1887.203914] ? kthread_blkcg+0x50/0x50\n [ 1887.204397] ret_from_fork_asm+0x11/0x20\n [ 1887.204913] \n [ 1887.204913] \n [ 1887.205209]\n [ 1887.205416] Allocated by task 2197:\n [ 1887.205881] kasan_set_track+0x3f/0x60\n [ 1887.206366] __kasan_kmalloc+0x6e/0x80\n [ 1887.206856] __kmalloc+0xac/0x1a0\n [ 1887.207293] btf_parse_fields+0xa15/0x1480\n [ 1887.207836] btf_parse_struct_metas+0x566/0x670\n [ 1887.208387] btf_new_fd+0x294/0x4d0\n [ 1887.208851] __sys_bpf+0x4ba/0x600\n [ 1887.209292] __x64_sys_bpf+0x41/0x50\n [ 1887.209762] do_syscall_64+0x4c/0xf0\n [ 1887.210222] entry_SYSCALL_64_after_hwframe+0x63/0x6b\n [ 1887.210868]\n [ 1887.211074] Freed by task 36:\n [ 1887.211460] kasan_set_track+0x3f/0x60\n [ 1887.211951] kasan_save_free_info+0x28/0x40\n [ 1887.212485] ____kasan_slab_free+0x101/0x180\n [ 1887.213027] __kmem_cache_free+0xe4/0x210\n [ 1887.213514] btf_free+0x5b/0x130\n [ 1887.213918] rcu_core+0x638/0xcc0\n [ 1887.214347] __do_softirq+0x114/0x37e\n\nThe error happens at bpf_rb_root_free+0x1f8/0x2b0:\n\n 00000000000034c0 :\n ; {\n 34c0: f3 0f 1e fa endbr64\n 34c4: e8 00 00 00 00 callq 0x34c9 \n 34c9: 55 pushq %rbp\n 34ca: 48 89 e5 movq %rsp, %rbp\n ...\n ; if (rec && rec->refcount_off >= 0 &&\n 36aa: 4d 85 ed testq %r13, %r13\n 36ad: 74 a9 je 0x3658 \n 36af: 49 8d 7d 10 leaq 0x10(%r13), %rdi\n 36b3: e8 00 00 00 00 callq 0x36b8 \n <==== kasan function\n 36b8: 45 8b 7d 10 movl 0x10(%r13), %r15d\n <==== use-after-free load\n 36bc: 45 85 ff testl %r15d, %r15d\n 36bf: 78 8c js 0x364d \n\nSo the problem \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate session id and tree id in compound request\n\n`smb2_get_msg()` in smb2_get_ksmbd_tcon() and smb2_check_user_session()\nwill always return the first request smb2 header in a compound request.\nif `SMB2_TREE_CONNECT_HE` is the first command in compound request, will\nreturn 0, i.e. The tree id check is skipped.\nThis patch use ksmbd_req_buf_next() to get current command in compound.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix out of bounds in init_smb2_rsp_hdr()\n\nIf client send smb2 negotiate request and then send smb1 negotiate\nrequest, init_smb2_rsp_hdr is called for smb1 negotiate request since\nneed_neg is set to false. This patch ignore smb1 packets after ->need_neg\nis set to false.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix slub overflow in ksmbd_decode_ntlmssp_auth_blob()\n\nIf authblob->SessionKey.Length is bigger than session key\nsize(CIFS_KEY_SIZE), slub overflow can happen in key exchange codes.\ncifs_arc4_crypt copy to session key array from SessionKey from client.

In blk_mq_queue_tag_busy_iter of blk-mq-tag.c, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-151939299

In l2tp_session_delete and related functions of l2tp_core.c, there is possible memory corruption due to a use after free. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-152735806

A NULL pointer dereference was discovered in elf_link_add_object_symbols in elflink.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.31.1. This occurs for a crafted ET_DYN with no program headers. A specially crafted ELF file allows remote attackers to cause a denial of service, as demonstrated by ld.

In GNU Binutils 2.31.1, there is a use-after-free in the error function in elfcomm.c when called from the process_archive function in readelf.c via a crafted ELF file.

The overlayfs implementation in the Linux kernel through 4.5.2 does not properly restrict the mount namespace, which allows local users to gain privileges by mounting an overlayfs filesystem on top of a FUSE filesystem, and then executing a crafted setuid program.

The overlayfs implementation in the Linux kernel through 4.5.2 does not properly maintain POSIX ACL xattr data, which allows local users to gain privileges by leveraging a group-writable setgid directory.

drivers/xen/usbback/usbback.c in linux-2.6.18-xen-3.4.0 (aka the Xen 3.4.x support patches for the Linux kernel 2.6.18), as used in the Linux kernel 2.6.x and 3.x in SUSE Linux distributions, allows guest OS users to obtain sensitive information from uninitialized locations in host OS kernel memory via unspecified vectors.

drivers/media/media-device.c in the Linux kernel before 3.11, as used in Android before 2016-08-05 on Nexus 5 and 7 (2013) devices, does not properly initialize certain data structures, which allows local users to obtain sensitive information via a crafted application, aka Android internal bug 28750150 and Qualcomm internal bug CR570757, a different vulnerability than CVE-2014-1739.

arch/arm/mm/dma-mapping.c in the Linux kernel before 3.13 on ARM platforms, as used in Android before 2016-08-05 on Nexus 5 and 7 (2013) devices, does not prevent executable DMA mappings, which might allow local users to gain privileges via a crafted application, aka Android internal bug 28803642 and Qualcomm internal bug CR642735.

The Linux kernel before 3.11 on ARM platforms, as used in Android before 2016-08-05 on Nexus 5 and 7 (2013) devices, does not properly consider user-space access to the TPIDRURW register, which allows local users to gain privileges via a crafted application, aka Android internal bug 28749743 and Qualcomm internal bug CR561044.

arch/arm64/include/asm/pgtable.h in the Linux kernel before 3.15-rc5-next-20140519, as used in Android before 2016-07-05 on Nexus 5X and 6P devices, mishandles execute-only pages, which allows attackers to gain privileges via a crafted application, aka Android internal bug 28557020.

The Btrfs implementation in the Linux kernel before 3.19 does not ensure that the visible xattr state is consistent with a requested replacement, which allows local users to bypass intended ACL settings and gain privileges via standard filesystem operations (1) during an xattr-replacement time window, related to a race condition, or (2) after an xattr-replacement attempt that fails because the data does not fit.

arch/mips/include/asm/thread_info.h in the Linux kernel before 3.14.8 on the MIPS platform does not configure _TIF_SECCOMP checks on the fast system-call path, which allows local users to bypass intended PR_SET_SECCOMP restrictions by executing a crafted application without invoking a trace or audit subsystem.

Off-by-one error in the bpf_jit_compile function in arch/x86/net/bpf_jit_comp.c in the Linux kernel before 3.1.8, when BPF JIT is enabled, allows local users to cause a denial of service (system crash) or possibly gain privileges via a long jump after a conditional jump.

The genlock_dev_ioctl function in genlock.c in the Genlock driver for the Linux kernel 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, does not properly initialize a certain data structure, which allows local users to obtain sensitive information from kernel stack memory via a crafted GENLOCK_IOC_EXPORT ioctl call.

The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the v6k and v7 ARM platforms do not validate certain addresses, which allows attackers to read or modify the contents of arbitrary kernel memory locations via a crafted application, as exploited in the wild against Android devices in October and November 2013.

arch/arm/kvm/arm.c in the Linux kernel before 3.10 on the ARM platform, when KVM is used, allows host OS users to cause a denial of service (NULL pointer dereference, OOPS, and host OS crash) or possibly have unspecified other impact by omitting vCPU initialization before a KVM_GET_REG_LIST ioctl call.

The MSM camera driver for the Linux kernel 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to obtain sensitive information from kernel stack memory via (1) a crafted MSM_MCR_IOCTL_EVT_GET ioctl call, related to drivers/media/platform/msm/camera_v1/mercury/msm_mercury_sync.c, or (2) a crafted MSM_JPEG_IOCTL_EVT_GET ioctl call, related to drivers/media/platform/msm/camera_v2/jpeg_10/msm_jpeg_sync.c.

Multiple stack-based buffer overflows in the MSM camera driver for the Linux kernel 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allow attackers to gain privileges via (1) a crafted VIDIOC_MSM_VPE_DEQUEUE_STREAM_BUFF_INFO ioctl call, related to drivers/media/platform/msm/camera_v2/pproc/vpe/msm_vpe.c, or (2) a crafted VIDIOC_MSM_CPP_DEQUEUE_STREAM_BUFF_INFO ioctl call, related to drivers/media/platform/msm/camera_v2/pproc/cpp/msm_cpp.c.

The CONFIG_STRICT_MEMORY_RWX implementation for the Linux kernel 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, does not properly consider certain memory sections, which makes it easier for attackers to bypass intended access restrictions by leveraging the presence of RWX memory at a fixed location.

The mp_get_count function in drivers/staging/sb105x/sb_pci_mp.c in the Linux kernel before 3.12 does not initialize a certain data structure, which allows local users to obtain sensitive information from kernel stack memory via a TIOCGICOUNT ioctl call.

The bcm_char_ioctl function in drivers/staging/bcm/Bcmchar.c in the Linux kernel before 3.12 does not initialize a certain data structure, which allows local users to obtain sensitive information from kernel memory via an IOCTL_BCM_GET_DEVICE_DRIVER_INFO ioctl call.

Multiple integer overflows in Alchemy LCD frame-buffer drivers in the Linux kernel before 3.12 allow local users to create a read-write memory mapping for the entirety of kernel memory, and consequently gain privileges, via crafted mmap operations, related to the (1) au1100fb_fb_mmap function in drivers/video/au1100fb.c and the (2) au1200fb_fb_mmap function in drivers/video/au1200fb.c.

Memory leak in the unshare_userns function in kernel/user_namespace.c in the Linux kernel before 3.10.6 allows local users to cause a denial of service (memory consumption) via an invalid CLONE_NEWUSER unshare call.