CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52908 – drm/amdgpu: Fix potential NULL dereference
https://notcve.org/view.php?id=CVE-2023-52908
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential NULL dereference Fix potential NULL dereference, in the case when "man", the resource manager might be NULL, when/if we print debug information. • https://git.kernel.org/stable/c/8ba7c55e112f4ffd2a95b99be1cb1c891ef08ba1 https://git.kernel.org/stable/c/80546eef216854a7bd47e39e828f04b406c00599 https://git.kernel.org/stable/c/f2faf0699af78968a27ca154bf76e94247f8c471 https://git.kernel.org/stable/c/0be7ed8e7eb15282b5d0f6fdfea884db594ea9bf •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52907 – nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
https://notcve.org/view.php?id=CVE-2023-52907
In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame() Fix a use-after-free that occurs in hcd when in_urb sent from pn533_usb_send_frame() is completed earlier than out_urb. Its callback frees the skb data in pn533_send_async_complete() that is used as a transfer buffer of out_urb. Wait before sending in_urb until the callback of out_urb is called. To modify the callback of out_urb alone, separate the complete function of out_urb and ack_urb. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in dummy_timer Call Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803) • https://git.kernel.org/stable/c/c46ee38620a2aa2b25b16bc9738ace80dbff76a4 https://git.kernel.org/stable/c/35529d6b827eedb6bf7e81130e4b7e0aba9e58d2 https://git.kernel.org/stable/c/321db5131c92983dac4f3338e8fbb6df214238c0 https://git.kernel.org/stable/c/9424d2205fe94a095fb9365ec0c6137f0b394a2b https://git.kernel.org/stable/c/0ca78c99656f5c448567db1e148367aa3b01c80a https://git.kernel.org/stable/c/39ae73e581112cfe27ba50aecb1c891ce57cecb1 https://git.kernel.org/stable/c/8998db5021a28ad67aa8d627bdb4226e4046ccc4 https://git.kernel.org/stable/c/9dab880d675b9d0dd56c6428e4e8352a3 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52906 – net/sched: act_mpls: Fix warning during failed attribute validation
https://notcve.org/view.php?id=CVE-2023-52906
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mpls: Fix warning during failed attribute validation The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid combination according to the comment above 'struct nla_policy': " Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN: NLA_BINARY Validation function called for the attribute. All other Unused - but note that it's a union " This can trigger the warning [1] in nla_get_range_unsigned() when validation of the attribute fails. Despite being of 'NLA_U32' type, the associated 'min'/'max' fields in the policy are negative as they are aliased by the 'validate' field. Fix by changing the attribute type to 'NLA_BINARY' which is consistent with the above comment and all other users of NLA_POLICY_VALIDATE_FN(). As a result, move the length validation to the validation function. No regressions in MPLS tests: # ./tdc.py -f tc-tests/actions/mpls.json [...] # echo $? 0 [1] WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118 nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117 Modules linked in: CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117 [...] Call Trace: <TASK> __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310 netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411 netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline] netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506 netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0x38f/0x500 net/socket.c:2482 ___sys_sendmsg net/socket.c:2536 [inline] __sys_sendmsg+0x197/0x230 net/socket.c:2565 __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd • https://git.kernel.org/stable/c/2a2ea50870baa3fb4de0872c5b60828138654ca7 https://git.kernel.org/stable/c/2b157c3c5d6b8ddca48d53c9e662032f65af8d61 https://git.kernel.org/stable/c/453277feb41c2235cf2c0de9209eef962c401457 https://git.kernel.org/stable/c/9e2c38827cdc6fdd3bb375c8607fc04d289756f9 https://git.kernel.org/stable/c/8a97b544b98e44f596219ebb290fd2ba2fd5d644 https://git.kernel.org/stable/c/9e17f99220d111ea031b44153fdfe364b0024ff2 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52905 – octeontx2-pf: Fix resource leakage in VF driver unbind
https://notcve.org/view.php?id=CVE-2023-52905
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix resource leakage in VF driver unbind resources allocated like mcam entries to support the Ntuple feature and hash tables for the tc feature are not getting freed in driver unbind. This patch fixes the issue. • https://git.kernel.org/stable/c/2da48943274712fc3204089d9a97078350765635 https://git.kernel.org/stable/c/c8ca0ad10df08ea36bcac1288062d567d22604c9 https://git.kernel.org/stable/c/53da7aec32982f5ee775b69dce06d63992ce4af3 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52903 – io_uring: lock overflowing for IOPOLL
https://notcve.org/view.php?id=CVE-2023-52903
In the Linux kernel, the following vulnerability has been resolved: io_uring: lock overflowing for IOPOLL syzbot reports an issue with overflow filling for IOPOLL: WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: events_unbound io_ring_exit_work Call trace: io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773 io_fill_cqe_req io_uring/io_uring.h:168 [inline] io_do_iopoll+0x474/0x62c io_uring/rw.c:1065 io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513 io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056 io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869 process_one_work+0x2d8/0x504 kernel/workqueue.c:2289 worker_thread+0x340/0x610 kernel/workqueue.c:2436 kthread+0x12c/0x158 kernel/kthread.c:376 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863 There is no real problem for normal IOPOLL as flush is also called with uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which __io_cqring_overflow_flush() happens from the CQ waiting path. • https://git.kernel.org/stable/c/de77faee280163ff03b7ab64af6c9d779a43d4c4 https://git.kernel.org/stable/c/ed4629d1e968359fbb91d0a3780b1e86a2c08845 https://git.kernel.org/stable/c/7fc3990dad04a677606337ebc61964094d6cb41b https://git.kernel.org/stable/c/544d163d659d45a206d8929370d5a2984e546cb7 •